From randell-ietf@jesup.org Wed Feb 1 09:02: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 D929211E8114 for ; Wed, 1 Feb 2012 09:02:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.768 X-Spam-Level: ** X-Spam-Status: No, score=2.768 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FF_IHOPE_YOU_SINK=2.166, HTML_MESSAGE=0.001, J_CHICKENPOX_23=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 tvdL3mKoPaYc for ; Wed, 1 Feb 2012 09:02:14 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 7412211E80B2 for ; Wed, 1 Feb 2012 09:02:10 -0800 (PST) Received: from [216.239.45.17] (helo=[192.168.48.73]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RsdZR-0007lf-Gd; Wed, 01 Feb 2012 11:02:09 -0600 Message-ID: <4F297011.1040507@jesup.org> Date: Wed, 01 Feb 2012 09:02:09 -0800 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: "rtcweb@ietf.org" , public-webrtc@w3.org References: <4F234B8B.4020204@jesup.org> <4F295660.3060001@jesup.org> In-Reply-To: <4F295660.3060001@jesup.org> Content-Type: multipart/alternative; boundary="------------010503020100000409080503" 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] JS app interaction with congestion control 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, 01 Feb 2012 17:02:15 -0000 This is a multi-part message in MIME format. --------------010503020100000409080503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This really is almost all W3c stuff; cc'ing that list where most discussion should occur. Updated suggestion based on Justin's comments: (largely for W3C discussion) This is rough, and a first cut, but we need to start somewhere. I propose we add a callback on PeerConnection and some attributes on it and MediaTracks: { ... // allow app to limit total bitrate used for the PeerConnection attribute unsigned long maxBitrate; attribute readonly unsigned long currentBitrate; // [Open issue] - how much smoothing? attribute Function? onBitrateChange; // don't notify until change since last notify is more than this attribute unsigned long minBitrateChangeToNotify; attribute Function? onResolutionChange; // not strictly needed // These are global settings that can be overridden on a per-track basis attribute float minFramerate; attribute float maxFramerate; // might not be needed attribute boolean preferMotion; // false means preference for Resolution } To each MediaTrack: { ... // If the app bumps up the currentBitrate of one track and doesn't lower another track, the // system will make cuts to keep the total bitrate within bounds. attribute unsigned long currentBitrate; attribute short priority; // for allocating bits // The rest of these are for video (is short guaranteed enough, always? Probably) attribute unsigned short width; // Let app override the values chosen automatically attribute unsigned short height; attribute float framerate; attribute float minFramerate; attribute float maxFramerate; // might not be needed attribute boolean preferMotion; // false means preference for Resolution // typically derived from QP attribute readonly unsigned short videoQuality; // audioQuality?? (samplerate?) } Should some of these be echoed in MediaTrackLists or MediaStreams? -- Randell Jesup randell-ietf@jesup.org --------------010503020100000409080503 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
This really is almost all W3c stuff; cc'ing that list where most discussion should occur.

Updated suggestion based on Justin's comments:  (largely for W3C discussion)

This is rough, and a first cut, but we need to start somewhere.

I propose we add a callback on PeerConnection and some attributes on it
and MediaTracks:

{
...
    // allow app to limit total bitrate used for the PeerConnection
    attribute unsigned long maxBitrate;
    attribute readonly unsigned long currentBitrate;  // [Open issue] - how much smoothing?

    attribute Function? onBitrateChange;
    // don't notify until change since last notify is more than this
    attribute unsigned long minBitrateChangeToNotify;
    attribute Function? onResolutionChange;  // not strictly needed

    // These are global settings that can be overridden on a per-track basis
    attribute float minFramerate;
    attribute float maxFramerate; // might not be needed
    attribute boolean preferMotion;  // false means preference for Resolution
}


To each MediaTrack:

{
...
    // If the app bumps up the currentBitrate of one track and doesn't lower another track, the
    // system will make cuts to keep the total bitrate within bounds.
    attribute unsigned long currentBitrate;
    attribute short priority;  // for allocating bits

    // The rest of these are for video (is short guaranteed enough, always?  Probably)
    attribute unsigned short width;  // Let app override the values chosen automatically
    attribute unsigned short height;
    attribute float framerate;
    attribute float minFramerate;
    attribute float maxFramerate; // might not be needed
    attribute boolean preferMotion;  // false means preference for Resolution

    // typically derived from QP
    attribute readonly unsigned short videoQuality;
    // audioQuality?? (samplerate?)

}

Should some of these be echoed in MediaTrackLists or MediaStreams? 


-- 
Randell Jesup
randell-ietf@jesup.org
--------------010503020100000409080503-- From HKaplan@acmepacket.com Wed Feb 1 13: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 22C6211E80D3 for ; Wed, 1 Feb 2012 13:59:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LGOSECe4IwwJ for ; Wed, 1 Feb 2012 13:59:26 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE4D11E8072 for ; Wed, 1 Feb 2012 13:59:26 -0800 (PST) Received: from MAIL1.acmepacket.com (10.0.0.21) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 1 Feb 2012 16:59:24 -0500 Received: from MAIL2.acmepacket.com ([169.254.2.176]) by Mail1.acmepacket.com ([169.254.1.108]) with mapi id 14.01.0270.001; Wed, 1 Feb 2012 16:59:24 -0500 From: Hadriel Kaplan To: "" Thread-Topic: SRTP and PFS Thread-Index: AQHM4SzC2+pSb88b8024NFqAh9OrLQ== Date: Wed, 1 Feb 2012 21:59:23 +0000 Message-ID: <7F79120F-8620-4923-8B5C-7C2B74C7F4FD@acmepacket.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="us-ascii" Content-ID: <40771213E55D9044AC66F5B632D6473E@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Subject: [rtcweb] SRTP and PFS 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, 01 Feb 2012 21:59:27 -0000 Howdy, A comment made today at the interim meeting was that DTLS-SRTP provided Per= fect Forward Secrecy (PFS), whereas SDES does not. I believe this was mean= t as (1) even if the long-term DTLS key of Alice were to be learned in the = future, that a previous call between Alice and Bob could not be decrypted, = and (2) that the web-server does not see the keys and thus compromising suc= h things as the web-server logs does not compromise previous call content. Since the topic came up with regard to comparison of DTLS-SRTP vs. SDES in = the context of interworking with non-WebRTC environments, I would point out= that using DTLS-SRTP in such environments does not provide PFS either. If= an interworking gateway is required, then even if it does DTLS-SRTP, both = of the encrypt/decrypt keys for SRTP for each call are known to the interwo= rking gateway and it will likely log them. Thus if the interworking gatewa= y's logs are compromised, any/all previous calls to/from it can be decrypte= d. -hadriel From alan.b.johnston@gmail.com Wed Feb 1 14:12: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 EC4FE11E8101 for ; Wed, 1 Feb 2012 14:12:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.776 X-Spam-Level: X-Spam-Status: No, score=-103.776 tagged_above=-999 required=5 tests=[AWL=-0.177, 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 M-ZbTCYft23B for ; Wed, 1 Feb 2012 14:12:06 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 107C611E8072 for ; Wed, 1 Feb 2012 14:12:05 -0800 (PST) Received: by obbwd15 with SMTP id wd15so2287641obb.31 for ; Wed, 01 Feb 2012 14:12:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=5umuDp/kPg16PdihEU6IbAi/Wq08Qe72iR49VOor+Xk=; b=x6yQGQPr4ZFKAkYjZGXHWFo+DBWQdcT6p20WDHAdNacX5j8+b/XmL4CBc2dQDnuz4E ujm0OU9ic1gfjC+YGhmtz6doHpZgWs5TrlOlS5itKxYN9jXeRVXDMYrDgm1c7ksg1uhV l2nqpPrsea0ddvknJ2w/jl5+hz3ubcssereKc= MIME-Version: 1.0 Received: by 10.182.8.66 with SMTP id p2mr385865oba.0.1328134325652; Wed, 01 Feb 2012 14:12:05 -0800 (PST) Received: by 10.182.75.136 with HTTP; Wed, 1 Feb 2012 14:12:05 -0800 (PST) In-Reply-To: <7F79120F-8620-4923-8B5C-7C2B74C7F4FD@acmepacket.com> References: <7F79120F-8620-4923-8B5C-7C2B74C7F4FD@acmepacket.com> Date: Wed, 1 Feb 2012 16:12:05 -0600 Message-ID: From: Alan Johnston To: Hadriel Kaplan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "" Subject: Re: [rtcweb] SRTP and PFS 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, 01 Feb 2012 22:12:07 -0000 Hadriel, Two points about this. The scenario of a gateway having access to the key is not exactly comparable with every web server in the path in addition to the gateway. Also, key destruction when a session ends is part of a key management protocol - if the gateway implements the key management, then it will do this. On the other hand, deletion of SDES keys by any web server that handles it is not part of any standard, nor is it practical. So I believe there is a difference, even when there is a gateway. When there isn't a gateway, there is an even bigger difference. - Alan - On Wed, Feb 1, 2012 at 3:59 PM, Hadriel Kaplan wro= te: > Howdy, > A comment made today at the interim meeting was that DTLS-SRTP provided P= erfect Forward Secrecy (PFS), whereas SDES does not. =A0I believe this was = meant as (1) even if the long-term DTLS key of Alice were to be learned in = the future, that a previous call between Alice and Bob could not be decrypt= ed, and (2) that the web-server does not see the keys and thus compromising= such things as the web-server logs does not compromise previous call conte= nt. > > Since the topic came up with regard to comparison of DTLS-SRTP vs. SDES i= n the context of interworking with non-WebRTC environments, I would point o= ut that using DTLS-SRTP in such environments does not provide PFS either. = =A0If an interworking gateway is required, then even if it does DTLS-SRTP, = both of the encrypt/decrypt keys for SRTP for each call are known to the in= terworking gateway and it will likely log them. =A0Thus if the interworking= gateway's logs are compromised, any/all previous calls to/from it can be d= ecrypted. > > -hadriel > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From magnus.westerlund@ericsson.com Wed Feb 1 14:31: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 625DB11E809F for ; Wed, 1 Feb 2012 14:31:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.03 X-Spam-Level: X-Spam-Status: No, score=-110.03 tagged_above=-999 required=5 tests=[AWL=0.569, 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 UY9y05-ZgV8n for ; Wed, 1 Feb 2012 14:31:22 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB1311E80FD for ; Wed, 1 Feb 2012 14:31:22 -0800 (PST) X-AuditID: c1b4fb3d-b7b26ae000000a35-a0-4f29bd392e7b Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 13.BB.02613.93DB92F4; Wed, 1 Feb 2012 23:31:21 +0100 (CET) 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.137.0; Wed, 1 Feb 2012 23:31:20 +0100 Message-ID: <4F29BD31.9040700@ericsson.com> Date: Wed, 1 Feb 2012 14:31:13 -0800 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [rtcweb] DoS attack despite ICE/STUN consent verification 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, 01 Feb 2012 22:31:23 -0000 Hi, As I brought up in yesterdays meeting I think there exist an attack that should be considered. I don't think it is super strong, but not without issues. Setting: Webserver is evil and have a target Alice. Alice can be a legacy device, like a SIP/SDP video phone. It knows the target is doing ICE and have Alice's ufrag and password and candidates. The server would like to hammer this target by utilizing its set of connected WebRTC clients (bob, charlie etc.). Thus it would like to ensure that it gets the browser to start sending RTP media when creating a PeerConnection in the clients. So the server gets the client to open PeerConnections towards the ICE parameters from the target (Alice). In default ICE behavior there is an optimization to allow the Offerer (Alice) to respond to STUN binding requests from Bob without having received an SDP answer from Bob. The STUN binding request must only have the Alice's ufrag and its password. This enables that Webrtc clients can get passed the data consent step with ICE capable end-point for which the ICE parameters can be retrieved. So from Alice perspective this attack will look like its offer got forked to many peers based on the many different peers that send STUN messages. The webserver could even provide SIP/SDP answers to alice with the webclients. But that is not necessary but is one variation of this. So what are the mitigations. A) If Alice receives SIP/SDP answers it can start triaging the many response and decide which it shouldn't answer to based on SIP/SDP information and the ignore in STUN layer based on the far side ufrag. B) Alice can stop answering to the STUN binding requests. However, that opens her up to denial of service attack if the method for Evil to acquire here ICE parameters is to snoop a legitimate intentional call. By not responding to a STUN binding response from different peers after having seen N peers allows evil to block the intended call. This mitigation may not work in cases where we can't enforce the browser to generate the ufrag on the WebRTC client side. Like what I objected to allow the ICE parameters to be set by SetLocalDescription. C) Continued Data consent: This can work but each WebRTC client will send for 30 s at least until it stops sending. The reason it may work is that default SIP/SDP ICE capable end-points may not support STUN binding responses during the call as that is not specified. It may however work if the implementation doesn't intentionally blocks binding responses after ICE processing has ceased. If Alice intentionally wants to block the media flows it can ensure that it doesn't send. D) RTP media adaptation / Congestion control. Alice can either refuse to send RTCP feedback or intentional feedback to reduced the transmission rate to a minimal. However, there is some lower limit where just basic probing traffic, low rate audio is sent over the media channel. However, it is not certain that this stops media transmission completely. E) If DTLS-SRTP is used then that handshake must complete. So if Alice doesn't support DTLS-SRTP it will not answer, thus preventing the WebRTC client to start sending media. If alice supports DTLS-SRTP then alice has some potential to refuse to respond based on the WebRTC clients used certificate. However, if it doesn't check that against an answer in the middle of the DTLS handshake, the WebRTC client could succeed in the DTLS-SRTP keying and start sending media, while Alice realizes that this is not the client it wants to talk to. So from my perspective, this is an attack that provides some potential for an overload / denial of service attack on Alice with the benefit that the one generating the traffic to Alice is the WebRTC clients. It will require some work from the webserver to keep the clients connect to some ICE candidate address which they expose or can get to expose. Comments on the strength of the attack and the weakness/strengths of the mitigations Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From bernard_aboba@hotmail.com Wed Feb 1 14:47: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 55A5F11E80A1 for ; Wed, 1 Feb 2012 14:47:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vzey7XYGLTSg for ; Wed, 1 Feb 2012 14:47:49 -0800 (PST) Received: from blu0-omc3-s37.blu0.hotmail.com (blu0-omc3-s37.blu0.hotmail.com [65.55.116.112]) by ietfa.amsl.com (Postfix) with ESMTP id C473111E809F for ; Wed, 1 Feb 2012 14:47:49 -0800 (PST) Received: from BLU0-P4-EAS132 ([65.55.116.72]) by blu0-omc3-s37.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 1 Feb 2012 14:47:48 -0800 X-Originating-IP: [64.134.238.29] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: References: <7F79120F-8620-4923-8B5C-7C2B74C7F4FD@acmepacket.com> From: Bernard Aboba Content-Type: text/plain; charset="us-ascii" In-Reply-To: <7F79120F-8620-4923-8B5C-7C2B74C7F4FD@acmepacket.com> Date: Wed, 1 Feb 2012 14:49:39 -0800 To: "rtcweb@ietf.org" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 (1.0) X-OriginalArrivalTime: 01 Feb 2012 22:47:48.0870 (UTC) FILETIME=[85A58260:01CCE133] Subject: Re: [rtcweb] Legacy interop requirements 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, 01 Feb 2012 22:47:50 -0000 It seems to me that the SDES discussion (and also the SRTP vs. RTP discussio= n) is really about requirements arising from legacy interop scenarios.=20 How about reposing the question as follows: "If we accept the legacy interop use cases, what are the implications for pr= otocol support?" As Hadriel pointed out, the entire body of legacy systems is not really rele= vant to this question, only those legacy systems which an RTCWEB browser wou= ld need to interoperate with.=20 If reposed this way, the question may be amenable to data-based responses al= ong various dimensions. For example, one could ask what fraction of the "pu= blic facing legacy systems" implement: SRTP vs. RTP-only (we talked about this today) Various codecs (I suspect that G.711 is 100%, but there may be others worth l= ooking at) (S)AVP vs. (S)AVPF Various SDP extensions (such as RFC 5939) As was noted, it's likely that the fraction of legacy system implementing IC= E is very low, so we can assume that a gateway is needed for that.=20 On Feb 1, 2012, at 13:59, "Hadriel Kaplan" wrote: > Howdy, > A comment made today at the interim meeting was that DTLS-SRTP provided Pe= rfect Forward Secrecy (PFS), whereas SDES does not. I believe this was mean= t as (1) even if the long-term DTLS key of Alice were to be learned in the f= uture, that a previous call between Alice and Bob could not be decrypted, an= d (2) that the web-server does not see the keys and thus compromising such t= hings as the web-server logs does not compromise previous call content. >=20 > Since the topic came up with regard to comparison of DTLS-SRTP vs. SDES in= the context of interworking with non-WebRTC environments, I would point out= that using DTLS-SRTP in such environments does not provide PFS either. If a= n interworking gateway is required, then even if it does DTLS-SRTP, both of t= he encrypt/decrypt keys for SRTP for each call are known to the interworking= gateway and it will likely log them. Thus if the interworking gateway's lo= gs are compromised, any/all previous calls to/from it can be decrypted. >=20 > -hadriel >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From randell-ietf@jesup.org Wed Feb 1 15:11: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 862EA21F865E for ; Wed, 1 Feb 2012 15:11:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.014 X-Spam-Level: * X-Spam-Status: No, score=1.014 tagged_above=-999 required=5 tests=[AWL=1.754, BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOvIlEVmK6Bw for ; Wed, 1 Feb 2012 15:11:43 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 9C50D21F865C for ; Wed, 1 Feb 2012 15:11:43 -0800 (PST) Received: from [216.239.45.17] (helo=[192.168.48.73]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RsjKu-0002aK-Vg for rtcweb@ietf.org; Wed, 01 Feb 2012 17:11:33 -0600 Message-ID: <4F29C6A4.6040903@jesup.org> Date: Wed, 01 Feb 2012 15:11:32 -0800 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7F79120F-8620-4923-8B5C-7C2B74C7F4FD@acmepacket.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] Legacy interop requirements 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, 01 Feb 2012 23:11:44 -0000 On 2/1/2012 2:49 PM, Bernard Aboba wrote: > It seems to me that the SDES discussion (and also the SRTP vs. RTP discussion) is really about requirements arising from legacy interop scenarios. > > How about reposing the question as follows: > > "If we accept the legacy interop use cases, what are the implications for protocol support?" > > As Hadriel pointed out, the entire body of legacy systems is not really relevant to this question, only those legacy systems which an RTCWEB browser would need to interoperate with. > > If reposed this way, the question may be amenable to data-based responses along various dimensions. For example, one could ask what fraction of the "public facing legacy systems" implement: > > SRTP vs. RTP-only (we talked about this today) > Various codecs (I suspect that G.711 is 100%, but there may be others worth looking at) IIRC there are some PSTN terminations (mostly in 3rd-world countries) which only allow G.729. We could decide to not care. Overall I doubt it's a major portion of the traffic, but it's non-zero. And G.729 is not something Mozilla is likely to ship. > (S)AVP vs. (S)AVPF > Various SDP extensions (such as RFC 5939) > > As was noted, it's likely that the fraction of legacy system implementing ICE is very low, so we can assume that a gateway is needed for that. Doesn't this invoke the consent issue? If that's the case, unless we expect that to change significantly, we'll be talking to gateways in most cases. So the question is down to the complexity/cost of the gateway. -- Randell Jesup randell-ietf@jesup.org From dwing@cisco.com Wed Feb 1 15:13: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 4E0A311E8117 for ; Wed, 1 Feb 2012 15:13:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.421 X-Spam-Level: X-Spam-Status: No, score=-105.421 tagged_above=-999 required=5 tests=[AWL=-1.122, BAYES_00=-2.599, MANGLED_HERE=2.3, 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 Db0k4gYEccgd for ; Wed, 1 Feb 2012 15:13:21 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 44B8511E80A1 for ; Wed, 1 Feb 2012 15:13:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=7416; q=dns/txt; s=iport; t=1328138001; x=1329347601; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=eGshfdUx11z4paAYU5adwrf9U6Nqb6BDY6ybjdF4HJI=; b=DmGrYejqVqvDt53ApNOeu2jq9lCd+P/BUNxlK1zCXK3PbSfM+QSz8gCU qKA5ht/zZD+PWzkJMuVB3MBq0NxHRby0tbxDYOysH+S9PT07mKAcHezH3 TOAAqqsncAYzGZZivAdySpxQXpW7rIntnFdF5eQId9z3YEE8SP226aQbK s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFABDGKU+rRDoG/2dsb2JhbABDoBOOb4EFgXIBAQEDAQEBAQUEBgEXRBAHAQECAgkPAgQBARkPBxkCDBUKCQgBAQQBEgsXh1oJmVsBnkoEiz0DBCsMAQEJBBQLDwqEDgISPoMaBIgOM4UFmlA X-IronPort-AV: E=Sophos;i="4.71,605,1320624000"; d="scan'208";a="28095655" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 01 Feb 2012 23:13:21 +0000 Received: from dwingWS ([10.21.74.228]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q11NDKMG003588; Wed, 1 Feb 2012 23:13:20 GMT From: "Dan Wing" To: "'Magnus Westerlund'" , References: <4F29BD31.9040700@ericsson.com> In-Reply-To: <4F29BD31.9040700@ericsson.com> Date: Wed, 1 Feb 2012 15:13:20 -0800 Message-ID: <0f8c01cce137$16a477f0$43ed67d0$@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: AczhMTxolWmWu6ewRuOeRAhjBwgWZAAAjwFQ Content-Language: en-us Subject: Re: [rtcweb] DoS attack despite ICE/STUN consent verification 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, 01 Feb 2012 23:13:22 -0000 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Magnus Westerlund > Sent: Wednesday, February 01, 2012 2:31 PM > To: rtcweb@ietf.org > Subject: [rtcweb] DoS attack despite ICE/STUN consent verification >=20 > Hi, >=20 > As I brought up in yesterdays meeting I think there exist an attack > that > should be considered. I don't think it is super strong, but not = without > issues. >=20 > Setting: >=20 > Webserver is evil and have a target Alice. Alice can be a legacy > device, like a SIP/SDP video phone.=20 Today I believe we reached tentative consensus to use un-authenticated STUN connectivity checks for 'continued consent' every 30 seconds. This = means an un-modified legacy device, such as Alice, will not authenticate = those incoming STUN connectivity checks (because they are not=20 authenticated) and will not respond to them. So, media will cease after = 30 seconds --completely unrelated to the attack described in this email. So, I believe for Alice to work at all, Alice needs: * a slight upgrade, so Alice responds to the 'continued consent' connectivity checks. * a media-handling device in front of her (e.g., SBC) to handle the 'continued consent' connectivity checks on her behalf. * a way to signal in SDP that 'continued consent' messages need=20 to be authenticated (or, rather, we need a way to indicate in SDP that the 'continued consent' messages can be unauthenticated). =20 > It knows the target is doing ICE and have > Alice's ufrag and password and candidates. The server would like to > hammer this target by utilizing its set of connected WebRTC clients > (bob, charlie etc.). Thus it would like to ensure that it gets the > browser to start sending RTP media when creating a PeerConnection in > the > clients. >=20 > So the server gets the client to open PeerConnections towards the ICE > parameters from the target (Alice). >=20 > In default ICE behavior there is an optimization to allow the Offerer > (Alice) to respond to STUN binding requests from Bob without having > received an SDP answer from Bob. The STUN binding request must only > have > the Alice's ufrag and its password. This enables that Webrtc clients > can > get passed the data consent step with ICE capable end-point for which > the ICE parameters can be retrieved. >=20 > So from Alice perspective this attack will look like its offer got > forked to many peers based on the many different peers that send STUN > messages. The webserver could even provide SIP/SDP answers to alice > with > the webclients. But that is not necessary but is one variation of = this. >=20 > So what are the mitigations. >=20 > A) If Alice receives SIP/SDP answers it can start triaging the many > response and decide which it shouldn't answer to based on SIP/SDP > information and the ignore in STUN layer based on the far side ufrag. That mitigation does not help much, because the attacker can cause=20 Bob, Charlie, etc., to all send back SIP answers and all send ICE=20 connectivity checks. > B) Alice can stop answering to the STUN binding requests. However, = that > opens her up to denial of service attack if the method for Evil to > acquire here ICE parameters is to snoop a legitimate intentional call. http://tools.ietf.org/html/rfc5245#section-18.4 suggests that signaling be encrypted with TLS (it says "SIPS") to protect against that attack. > By not responding to a STUN binding response from different peers = after > having seen N peers allows evil to block the intended call. This > mitigation may not work in cases where we can't enforce the browser to > generate the ufrag on the WebRTC client side. Like what I objected to > allow the ICE parameters to be set by SetLocalDescription. >=20 > C) Continued Data consent: This can work but each WebRTC client will > send for 30 s at least until it stops sending. The reason it may work > is > that default SIP/SDP ICE capable end-points may not support STUN > binding > responses during the call as that is not specified. It may however = work > if the implementation doesn't intentionally blocks binding responses > after ICE processing has ceased. If Alice intentionally wants to block > the media flows it can ensure that it doesn't send. >=20 > D) RTP media adaptation / Congestion control. Alice can either refuse > to > send RTCP feedback or intentional feedback to reduced the transmission > rate to a minimal. However, there is some lower limit where just basic > probing traffic, low rate audio is sent over the media channel. > However, > it is not certain that this stops media transmission completely. >=20 > E) If DTLS-SRTP is used then that handshake must complete. So if Alice > doesn't support DTLS-SRTP it will not answer, thus preventing the > WebRTC client to start sending media. That somewhat depends on if we decide to allow RTP, and if the attackers (Bob, Charlie, etc.) have RTP media to send. =20 (Note: By allowing RTP, or allowing SDESC-keyed SRTP, we avoid=20 one of the worries of DTLS-SRTP which is its delayed media establishment (due to additional round trips of DTLS). But we also increase complexity. Just something I thought I might throw into this thread.) > If alice supports DTLS-SRTP then alice > has some potential to refuse to respond based on the WebRTC clients > used > certificate. However, if it doesn't check that against an answer in = the > middle of the DTLS handshake, the WebRTC client could succeed in the > DTLS-SRTP keying and start sending media, while Alice realizes that > this > is not the client it wants to talk to. If Bob, Charlie, etc., all send back SDP Answers, Alice will most responsibly do DTLS-SRTP handshakes with all of them -- in order to reduce the eventual media cut-through delay. What is said now, about Alice's expected behavior in that regard, is http://tools.ietf.org/html/rfc5763#section-6.2 > So from my perspective, this is an attack that provides some potential > for an overload / denial of service attack on Alice with the benefit > that the one generating the traffic to Alice is the WebRTC clients. It > will require some work from the webserver to keep the clients connect > to > some ICE candidate address which they expose or can get to expose. >=20 > Comments on the strength of the attack and the weakness/strengths of > the mitigations It seems a legacy device, Alice, cannot work without software upgrade or a media device in front of it. =20 I don't have any great ideas to solve the attack, though. Will think about it more. -d > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From HKaplan@acmepacket.com Wed Feb 1 15:36: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 E4F1011E8132 for ; Wed, 1 Feb 2012 15:36:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.465, 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 4zPbjd2vQKuX for ; Wed, 1 Feb 2012 15:36:58 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id E834A11E812D for ; Wed, 1 Feb 2012 15:36:57 -0800 (PST) Received: from MAIL1.acmepacket.com (10.0.0.21) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 1 Feb 2012 18:36:56 -0500 Received: from MAIL2.acmepacket.com ([169.254.2.176]) by Mail1.acmepacket.com ([169.254.1.108]) with mapi id 14.01.0270.001; Wed, 1 Feb 2012 18:36:56 -0500 From: Hadriel Kaplan To: Alan Johnston Thread-Topic: [rtcweb] SRTP and PFS Thread-Index: AQHM4TphV5A7mlcq4Uy7o/e7om9h1A== Date: Wed, 1 Feb 2012 23:36:55 +0000 Message-ID: References: <7F79120F-8620-4923-8B5C-7C2B74C7F4FD@acmepacket.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <38943CE12618F54C9A724586F3EDACA3@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] SRTP and PFS 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, 01 Feb 2012 23:36:59 -0000 On Feb 1, 2012, at 5:12 PM, Alan Johnston wrote: > Hadriel, > Two points about this. The scenario of a gateway having access to the > key is not exactly comparable with every web server in the path in > addition to the gateway. Also, key destruction when a session ends is > part of a key management protocol - if the gateway implements the key > management, then it will do this. =20 I'm not sure I understand what you mean - there's nothing built into the DT= LS-SRTP protocol that auto-magically deletes the generated SRTP keys from l= ocal logs. And if the interworking gateway does SIPREC or CALEA, it might = even export those keys off-box. (although generally they just mirror the RT= P post-decrypt/pre-encrypt, afaict) > On the other hand, deletion of SDES > keys by any web server that handles it is not part of any standard, > nor is it practical. >=20 > So I believe there is a difference, even when there is a gateway. > When there isn't a gateway, there is an even bigger difference. Right, but I'm not claiming SDES has PFS - I'm only stating that DTLS-SRTP = does not either. -hadriel From juberti@google.com Wed Feb 1 15:42: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 2F2DB11E812D for ; Wed, 1 Feb 2012 15:42:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.712 X-Spam-Level: X-Spam-Status: No, score=-102.712 tagged_above=-999 required=5 tests=[AWL=0.264, 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 aqI+xBmVCa37 for ; Wed, 1 Feb 2012 15:42:30 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2B40E11E8124 for ; Wed, 1 Feb 2012 15:42:30 -0800 (PST) Received: by obbwd15 with SMTP id wd15so2397110obb.31 for ; Wed, 01 Feb 2012 15:42:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:from:date:message-id:subject:to:x-system-of-record :content-type; bh=rI2zMzGUa9kPnhVQkfRmH4fx+ahkoroIkLeu1ugVHic=; b=BMi/zFLSbrliW+WOG1WlxZkw8OxJLJ24Io7G+V+V9OL/L7gl6RS8hC2Z8m/jjlOkFY BTsAmcl/ljBOzdA5ifdQGq4BYZI/kvzJGMePxqbgobZMWxMr7oA2V6IN6pSfEzzlBMay ZXftLlSHQdYzhLXJM63wm8OFbM0hB7t6ouog8= Received: by 10.50.89.232 with SMTP id br8mr9563047igb.30.1328139749732; Wed, 01 Feb 2012 15:42:29 -0800 (PST) Received: by 10.50.89.232 with SMTP id br8mr9563042igb.30.1328139749647; Wed, 01 Feb 2012 15:42:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.85.132 with HTTP; Wed, 1 Feb 2012 15:42:06 -0800 (PST) From: Justin Uberti Date: Wed, 1 Feb 2012 15:42:06 -0800 Message-ID: To: rtcweb@ietf.org X-System-Of-Record: true Content-Type: multipart/alternative; boundary=e89a8f3ba429fd64c604b7efa14a Subject: [rtcweb] ICE with only TURN candidates: what should rel-addr/rel-port be? 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, 01 Feb 2012 23:42:31 -0000 --e89a8f3ba429fd64c604b7efa14a Content-Type: text/plain; charset=UTF-8 http://tools.ietf.org/html/rfc5245, section 15.1: and : convey transport addresses related to the candidate, useful for diagnostics and other purposes. and MUST be present for server reflexive, peer reflexive, and relayed candidates. If a candidate is server or peer reflexive, and are equal to the base for that server or peer reflexive candidate. If the candidate is relayed, and is equal to the mapped address in the Allocate response that provided the client with that relayed candidate (see Appendix B.3 for a discussion of its purpose). If the candidate is a host candidate, and MUST be omitted. Clearly we don't want to send out the base address when doing TURN-only, but according to the spec, rel-addr/rel-port must be supplied. What's the right way to handle this? --e89a8f3ba429fd64c604b7efa14a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 
http://tools.ietf.org/html/rfc5245, section 15.1: =
    =C2=A0
      <rel-addr> and=
 <rel-port>:  convey transport addresses related to the
      candidate, useful for diagnostics and other purposes. <rel-addr>=
;
      and <rel-port> MUST be present for server reflexive, peer
      reflexive, and relayed candidates.  If a candidate is server or
      peer reflexive, <rel-addr> and <rel-port> are equal to th=
e base
      for that server or peer reflexive candidate.  If the candidate is
      relayed, <rel-addr> and <rel-port> is equal to the mapped=
 address
      in the Allocate response that provided the client with that
      relayed candidate (see Appendix B.3 for a discussion of its
      purpose).  If the candidate is a host candidate, <rel-addr> and
      <rel-port> MUST be omitted.


Clearly we don't want to se=
nd out the base address when doing TURN-only, but according to the spec, re=
l-addr/rel-port must be supplied. What's the right way to handle this?<=
/font>
--e89a8f3ba429fd64c604b7efa14a-- From magnus.westerlund@ericsson.com Wed Feb 1 16:02: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 50D3A11E8124 for ; Wed, 1 Feb 2012 16:02:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.053 X-Spam-Level: X-Spam-Status: No, score=-110.053 tagged_above=-999 required=5 tests=[AWL=0.546, 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 UMJitu80i6kh for ; Wed, 1 Feb 2012 16:02:50 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB1611E811B for ; Wed, 1 Feb 2012 16:02:50 -0800 (PST) X-AuditID: c1b4fb3d-b7b26ae000000a35-8f-4f29d2a92de2 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 5C.BF.02613.9A2D92F4; Thu, 2 Feb 2012 01:02:49 +0100 (CET) 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.137.0; Thu, 2 Feb 2012 01:02:48 +0100 Message-ID: <4F29D2A6.4090802@ericsson.com> Date: Wed, 1 Feb 2012 16:02:46 -0800 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [rtcweb] Confirming consensus from Interim: Data protocol and security mechanism 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, 02 Feb 2012 00:02:51 -0000 WG, This is a 2 week call for confirming the consensus of the interim meeting regarding data transport. The WG members not present at the interim are requested to indicate support or objections on the consensus from the interim. This email contains two calls related to the data transport. Please provide any input no later than the 15th of February. The jabber logs are pretty well capturing the discussion. Please see from 00:18:36 in http://www.ietf.org/jabber/logs/rtcweb/2012-02-01.html The first consensus call made was which transport protocol that should be used. Based on the discussion it was clear that SCTP was favored and that was confirmed by the consensus call. Where 19 participants preferred SCTP as the transport protocol for the data channel and 3 desired something else. The WG declared clear consensus for using SCTP as the transport protocol for data. Does the WG participants not present agrees or objects? The seconds consensus call was on the order of SCTP and DTLS on top of UDP. The two alternatives are: SCTP/DTLS/UDP or DTLS/SCTP/UDP. This was a unanimous consensus, where 18 preferred SCTP/DTLS/UDP, and no for the other order. Does the WG participants not present agrees or objects? 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 randell-ietf@jesup.org Wed Feb 1 16:25: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 1556411E8137 for ; Wed, 1 Feb 2012 16:25:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.792 X-Spam-Level: X-Spam-Status: No, score=-0.792 tagged_above=-999 required=5 tests=[AWL=1.807, 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 kdEJYJ4vvbDC for ; Wed, 1 Feb 2012 16:25:42 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 932F811E8132 for ; Wed, 1 Feb 2012 16:25:42 -0800 (PST) Received: from [216.239.45.17] (helo=[192.168.48.73]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RskUg-0000HZ-4m for rtcweb@ietf.org; Wed, 01 Feb 2012 18:25:42 -0600 Message-ID: <4F29D805.4010805@jesup.org> Date: Wed, 01 Feb 2012 16:25:41 -0800 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7F79120F-8620-4923-8B5C-7C2B74C7F4FD@acmepacket.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] SRTP and PFS 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, 02 Feb 2012 00:25:44 -0000 On 2/1/2012 3:36 PM, Hadriel Kaplan wrote: > On Feb 1, 2012, at 5:12 PM, Alan Johnston wrote: > >> Hadriel, >> Two points about this. The scenario of a gateway having access to the >> key is not exactly comparable with every web server in the path in >> addition to the gateway. Also, key destruction when a session ends is >> part of a key management protocol - if the gateway implements the key >> management, then it will do this. > I'm not sure I understand what you mean - there's nothing built into the DTLS-SRTP protocol that auto-magically deletes the generated SRTP keys from local logs. And if the interworking gateway does SIPREC or CALEA, it might even export those keys off-box. (although generally they just mirror the RTP post-decrypt/pre-encrypt, afaict) True, but this isn't an aspect of DTLS-SRTP as a protocol; this is an endpoint issue. >> On the other hand, deletion of SDES >> keys by any web server that handles it is not part of any standard, >> nor is it practical. >> >> So I believe there is a difference, even when there is a gateway. >> When there isn't a gateway, there is an even bigger difference. > > Right, but I'm not claiming SDES has PFS - I'm only stating that DTLS-SRTP does not either. I'd rephrase that as "if you don't trust the other endpoint, no protocol can give PFS (or any security against that endpoint), only security against intermediate attackers". -- Randell Jesup randell-ietf@jesup.org From alan.b.johnston@gmail.com Wed Feb 1 17:21: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 9F2FC1F0C36 for ; Wed, 1 Feb 2012 17:21:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.747 X-Spam-Level: X-Spam-Status: No, score=-103.747 tagged_above=-999 required=5 tests=[AWL=-0.148, 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 zPsXNBns29qr for ; Wed, 1 Feb 2012 17:21:59 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 145D011E8087 for ; Wed, 1 Feb 2012 17:21:59 -0800 (PST) Received: by obbwd15 with SMTP id wd15so2516670obb.31 for ; Wed, 01 Feb 2012 17:21:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=jNQsh3u9+6QXvw6/OqVVgTA2V1kX8doBfuq+HpYgf+A=; b=VzCJkTce9gVtraQ/Cb67Ugv89alQ9ZHRQeFZAYImfulE4dYiNQ1UfzVWic7NrUMPX8 M8ajn5UZIfYET9wyveplAoUS2pfgtK8cZLs8yao4F8/d6D8IkoM6iETWH/gpeTQM0cAx Xr0Gpt/xmyLZjujtm0atGalKCTU+T3FDPHJAU= MIME-Version: 1.0 Received: by 10.182.41.6 with SMTP id b6mr826282obl.10.1328145718714; Wed, 01 Feb 2012 17:21:58 -0800 (PST) Received: by 10.182.75.136 with HTTP; Wed, 1 Feb 2012 17:21:58 -0800 (PST) In-Reply-To: <4F29D805.4010805@jesup.org> References: <7F79120F-8620-4923-8B5C-7C2B74C7F4FD@acmepacket.com> <4F29D805.4010805@jesup.org> Date: Wed, 1 Feb 2012 19:21:58 -0600 Message-ID: From: Alan Johnston To: HKaplan@acmepacket.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SRTP and PFS 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, 02 Feb 2012 01:21:59 -0000 Hadriel, See below. - Alan - On Wed, Feb 1, 2012 at 6:25 PM, Randell Jesup wrot= e: > On 2/1/2012 3:36 PM, Hadriel Kaplan wrote: >> >> On Feb 1, 2012, at 5:12 PM, Alan Johnston wrote: >> >>> Hadriel, >>> Two points about this. =A0The scenario of a gateway having access to th= e >>> key is not exactly comparable with every web server in the path in >>> addition to the gateway. =A0Also, key destruction when a session ends i= s >>> part of a key management protocol - if the gateway implements the key >>> management, then it will do this. >> >> I'm not sure I understand what you mean - there's nothing built into the >> DTLS-SRTP protocol that auto-magically deletes the generated SRTP keys f= rom >> local logs. Interesting - I did a quick search and you may be right. Perhaps Ekr can comment on this. For an example of how this should be done, see http://tools.ietf.org/html/rfc6189#section-4.7.3 =A0And if the interworking gateway does SIPREC or CALEA, it might >> even export those keys off-box. (although generally they just mirror the= RTP >> post-decrypt/pre-encrypt, afaict) In that case, I don't care what it does with the keys as long as they are treated and handled as cryptographic material. I don't think that your average web server run by your average ISP has any notion how keying material should be handled - nor should they need to. > > > True, but this isn't an aspect of DTLS-SRTP as a protocol; this is an > endpoint issue. > >>> On the other hand, deletion of SDES >>> keys by any web server that handles it is not part of any standard, >>> nor is it practical. >>> >>> So I believe there is a difference, even when there is a gateway. >>> When there isn't a gateway, there is an even bigger difference. >> >> >> Right, but I'm not claiming SDES has PFS - I'm only stating that DTLS-SR= TP >> does not either. > > > > I'd rephrase that as "if you don't trust the other endpoint, no protocol = can > give PFS (or any security against that endpoint), only security against > intermediate attackers". > > -- > Randell Jesup > randell-ietf@jesup.org > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From ekr@rtfm.com Wed Feb 1 17:29: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 996A311E80AB for ; Wed, 1 Feb 2012 17:29:09 -0800 (PST) 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 ud8X7M-Z-pw0 for ; Wed, 1 Feb 2012 17:29:09 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 09EF611E8087 for ; Wed, 1 Feb 2012 17:29:08 -0800 (PST) Received: by vbbfr13 with SMTP id fr13so1566058vbb.31 for ; Wed, 01 Feb 2012 17:29:08 -0800 (PST) Received: by 10.52.19.232 with SMTP id i8mr345649vde.24.1328146148498; Wed, 01 Feb 2012 17:29:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.71.19 with HTTP; Wed, 1 Feb 2012 17:28:28 -0800 (PST) X-Originating-IP: [216.239.45.17] In-Reply-To: References: <7F79120F-8620-4923-8B5C-7C2B74C7F4FD@acmepacket.com> <4F29D805.4010805@jesup.org> From: Eric Rescorla Date: Wed, 1 Feb 2012 17:28:28 -0800 Message-ID: To: Alan Johnston Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SRTP and PFS 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, 02 Feb 2012 01:29:09 -0000 On Wed, Feb 1, 2012 at 5:21 PM, Alan Johnston w= rote: > Hadriel, > > See below. > > - Alan - > > On Wed, Feb 1, 2012 at 6:25 PM, Randell Jesup wr= ote: >> On 2/1/2012 3:36 PM, Hadriel Kaplan wrote: >>> >>> On Feb 1, 2012, at 5:12 PM, Alan Johnston wrote: >>> >>>> Hadriel, >>>> Two points about this. =A0The scenario of a gateway having access to t= he >>>> key is not exactly comparable with every web server in the path in >>>> addition to the gateway. =A0Also, key destruction when a session ends = is >>>> part of a key management protocol - if the gateway implements the key >>>> management, then it will do this. >>> >>> I'm not sure I understand what you mean - there's nothing built into th= e >>> DTLS-SRTP protocol that auto-magically deletes the generated SRTP keys = from >>> local logs. > > Interesting - I did a quick search and you may be right. =A0Perhaps Ekr > can comment on this. I think this is mostly a stylistic issue. I.e., TLS just doesn't give a lot of implementation advice and neither does DTLS and DTLS-SRTP. > For an example of how this should be done, see > > =A0http://tools.ietf.org/html/rfc6189#section-4.7.3 I'd be happy to add appropriate text to the arch document. I'll put it on my TODO list but please remind me if I forget :) Best, -Ekr From magnus.westerlund@ericsson.com Wed Feb 1 18:06: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 6A3E211E809A for ; Wed, 1 Feb 2012 18:06:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.924 X-Spam-Level: X-Spam-Status: No, score=-108.924 tagged_above=-999 required=5 tests=[AWL=-0.625, BAYES_00=-2.599, MANGLED_HERE=2.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 tyiLVgeDNkn7 for ; Wed, 1 Feb 2012 18:06:43 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 0A06811E8087 for ; Wed, 1 Feb 2012 18:06:42 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-3d-4f29efb15457 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 9D.F4.27041.1BFE92F4; Thu, 2 Feb 2012 03:06:41 +0100 (CET) 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.137.0; Thu, 2 Feb 2012 03:06:40 +0100 Message-ID: <4F29EFAD.3090307@ericsson.com> Date: Wed, 1 Feb 2012 18:06:37 -0800 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Dan Wing References: <4F29BD31.9040700@ericsson.com> <0f8c01cce137$16a477f0$43ed67d0$@com> In-Reply-To: <0f8c01cce137$16a477f0$43ed67d0$@com> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DoS attack despite ICE/STUN consent verification 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, 02 Feb 2012 02:06:44 -0000 On 2012-02-01 15:13, Dan Wing wrote: >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >> Behalf Of Magnus Westerlund >> Sent: Wednesday, February 01, 2012 2:31 PM >> To: rtcweb@ietf.org >> Subject: [rtcweb] DoS attack despite ICE/STUN consent verification >> >> Hi, >> >> As I brought up in yesterdays meeting I think there exist an attack >> that >> should be considered. I don't think it is super strong, but not without >> issues. >> >> Setting: >> >> Webserver is evil and have a target Alice. Alice can be a legacy >> device, like a SIP/SDP video phone. > > Today I believe we reached tentative consensus to use un-authenticated > STUN connectivity checks for 'continued consent' every 30 seconds. This > means an un-modified legacy device, such as Alice, will not authenticate > those incoming STUN connectivity checks (because they are not > authenticated) and will not respond to them. So, media will cease after > 30 seconds --completely unrelated to the attack described in this email. Yes, I think that is the most likely. Unless Alice has done a poor implementation and left her STUN servers with configured ufrag and password after the ICE processing concluded. Secondly, I think 30 seconds of media gives a reasonably high amplification factor. > > So, I believe for Alice to work at all, Alice needs: > > * a slight upgrade, so Alice responds to the 'continued consent' > connectivity checks. > > * a media-handling device in front of her (e.g., SBC) > to handle the 'continued consent' connectivity checks on > her behalf. > > * a way to signal in SDP that 'continued consent' messages need > to be authenticated (or, rather, we need a way to indicate in > SDP that the 'continued consent' messages can be unauthenticated). > My point is that Alice is not supposed to accept this media data as they where not intended to communicate with the WebRTC client. That is a result of the evil webserver's attack. But, if they where intending to communicate I agree that something like what you list would be needed. > >> It knows the target is doing ICE and have >> Alice's ufrag and password and candidates. The server would like to >> hammer this target by utilizing its set of connected WebRTC clients >> (bob, charlie etc.). Thus it would like to ensure that it gets the >> browser to start sending RTP media when creating a PeerConnection in >> the >> clients. >> >> So the server gets the client to open PeerConnections towards the ICE >> parameters from the target (Alice). >> >> In default ICE behavior there is an optimization to allow the Offerer >> (Alice) to respond to STUN binding requests from Bob without having >> received an SDP answer from Bob. The STUN binding request must only >> have >> the Alice's ufrag and its password. This enables that Webrtc clients >> can >> get passed the data consent step with ICE capable end-point for which >> the ICE parameters can be retrieved. >> >> So from Alice perspective this attack will look like its offer got >> forked to many peers based on the many different peers that send STUN >> messages. The webserver could even provide SIP/SDP answers to alice >> with >> the webclients. But that is not necessary but is one variation of this. >> >> So what are the mitigations. >> >> A) If Alice receives SIP/SDP answers it can start triaging the many >> response and decide which it shouldn't answer to based on SIP/SDP >> information and the ignore in STUN layer based on the far side ufrag. > > That mitigation does not help much, because the attacker can cause > Bob, Charlie, etc., to all send back SIP answers and all send ICE > connectivity checks. > >> B) Alice can stop answering to the STUN binding requests. However, that >> opens her up to denial of service attack if the method for Evil to >> acquire here ICE parameters is to snoop a legitimate intentional call. > > http://tools.ietf.org/html/rfc5245#section-18.4 suggests that signaling > be encrypted with TLS (it says "SIPS") to protect against that attack. Yes, agreed. However, there seems to be multiple methods to get hold of Alice's ICE parameters. Different depending on Alice role and communication patterns. One is clearly to snoop the SIP communication. Another is to actually start up a call with Alice. > >> By not responding to a STUN binding response from different peers after >> having seen N peers allows evil to block the intended call. This >> mitigation may not work in cases where we can't enforce the browser to >> generate the ufrag on the WebRTC client side. Like what I objected to >> allow the ICE parameters to be set by SetLocalDescription. >> >> C) Continued Data consent: This can work but each WebRTC client will >> send for 30 s at least until it stops sending. The reason it may work >> is >> that default SIP/SDP ICE capable end-points may not support STUN >> binding >> responses during the call as that is not specified. It may however work >> if the implementation doesn't intentionally blocks binding responses >> after ICE processing has ceased. If Alice intentionally wants to block >> the media flows it can ensure that it doesn't send. >> >> D) RTP media adaptation / Congestion control. Alice can either refuse >> to >> send RTCP feedback or intentional feedback to reduced the transmission >> rate to a minimal. However, there is some lower limit where just basic >> probing traffic, low rate audio is sent over the media channel. >> However, >> it is not certain that this stops media transmission completely. >> >> E) If DTLS-SRTP is used then that handshake must complete. So if Alice >> doesn't support DTLS-SRTP it will not answer, thus preventing the >> WebRTC client to start sending media. > > That somewhat depends on if we decide to allow RTP, and if the > attackers (Bob, Charlie, etc.) have RTP media to send. > > (Note: By allowing RTP, or allowing SDESC-keyed SRTP, we avoid > one of the worries of DTLS-SRTP which is its delayed media > establishment (due to additional round trips of DTLS). But we > also increase complexity. Just something I thought I might throw > into this thread.) Yes, I however wanted to point out that DTLS-SRTP is a second barrier for consent establishment prior to media transmission. If one has plain RTP then media transmission could start directly after ICE nominates the candidate pair to Alice. > >> If alice supports DTLS-SRTP then alice >> has some potential to refuse to respond based on the WebRTC clients >> used >> certificate. However, if it doesn't check that against an answer in the >> middle of the DTLS handshake, the WebRTC client could succeed in the >> DTLS-SRTP keying and start sending media, while Alice realizes that >> this >> is not the client it wants to talk to. > > If Bob, Charlie, etc., all send back SDP Answers, Alice will most > responsibly do DTLS-SRTP handshakes with all of them -- in order > to reduce the eventual media cut-through delay. > > What is said now, about Alice's expected behavior in that > regard, is http://tools.ietf.org/html/rfc5763#section-6.2 Yes, and this points to a security issue that needs to be specifically discussed in the context of WebRTC. > >> So from my perspective, this is an attack that provides some potential >> for an overload / denial of service attack on Alice with the benefit >> that the one generating the traffic to Alice is the WebRTC clients. It >> will require some work from the webserver to keep the clients connect >> to >> some ICE candidate address which they expose or can get to expose. >> >> Comments on the strength of the attack and the weakness/strengths of >> the mitigations > > It seems a legacy device, Alice, cannot work without software upgrade > or a media device in front of it. I think it does in fact works in the sense that one may end up in a state where RTP media flows to a legacy device without actually having provided the level of consent that we desire for WebRTC due to the early media optimizations in these end-points. > > I don't have any great ideas to solve the attack, though. Will think > about it more. > Thanks, for the feedback. 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 nishida@sfc.wide.ad.jp Wed Feb 1 20:20: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 94A7411E8087 for ; Wed, 1 Feb 2012 20:20:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.814 X-Spam-Level: X-Spam-Status: No, score=-98.814 tagged_above=-999 required=5 tests=[AWL=-0.340, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, 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 J2Z5tXEdfjr3 for ; Wed, 1 Feb 2012 20:20:32 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id 1524711E807F for ; Wed, 1 Feb 2012 20:20:30 -0800 (PST) Received: from mail-lpp01m020-f172.google.com (mail-lpp01m020-f172.google.com [209.85.217.172]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 663BB2780A5 for ; Thu, 2 Feb 2012 13:20:24 +0900 (JST) Received: by lbbgk8 with SMTP id gk8so331852lbb.31 for ; Wed, 01 Feb 2012 20:20:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.85.73 with SMTP id f9mr333076lbz.25.1328156421020; Wed, 01 Feb 2012 20:20:21 -0800 (PST) Received: by 10.112.104.74 with HTTP; Wed, 1 Feb 2012 20:20:20 -0800 (PST) In-Reply-To: <4F29D2A6.4090802@ericsson.com> References: <4F29D2A6.4090802@ericsson.com> Date: Wed, 1 Feb 2012 20:20:20 -0800 Message-ID: From: Yoshifumi Nishida To: "rtcweb@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [rtcweb] Confirming consensus from Interim: Data protocol and security mechanism 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, 02 Feb 2012 04:20:32 -0000 Hello, On Wed, Feb 1, 2012 at 4:02 PM, Magnus Westerlund wrote: > > The seconds consensus call was on the order of SCTP and DTLS on top of > UDP. The two alternatives are: SCTP/DTLS/UDP or DTLS/SCTP/UDP. This was > a unanimous consensus, where 18 preferred SCTP/DTLS/UDP, and no for the > other order. Does the WG participants not present agrees or objects? This is not an objection. I'm just curious.. If we think about the situation where we want to use SCTP without UDP encaps, DTLS/SCTP/UDP seems to be more straightforward approach to me. Also, we already have RFC6083. I'm wondering why there was no support for this. Thanks, -- Yoshifumi Nishida From aeh@db.org Thu Feb 2 05:26: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 858C521F8869 for ; Thu, 2 Feb 2012 05:26:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywt8PP7OpUwH for ; Thu, 2 Feb 2012 05:26:23 -0800 (PST) Received: from mailstore05.sysedata.no (mailstore05.sysedata.no [195.159.29.9]) by ietfa.amsl.com (Postfix) with ESMTP id DE8F321F8868 for ; Thu, 2 Feb 2012 05:26:22 -0800 (PST) Received: from [64.103.25.233] (helo=[10.54.86.168]) by mailstore05.sysedata.no with esmtpa (Exim 4.72) (envelope-from ) id 1Rswg7-0000bP-RX; Thu, 02 Feb 2012 14:26:19 +0100 Message-ID: <4F2A8EFB.2080308@db.org> Date: Thu, 02 Feb 2012 14:26:19 +0100 From: "Alfred E. Heggestad" User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11 MIME-Version: 1.0 To: Justin Uberti References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] ICE with only TURN candidates: what should rel-addr/rel-port be? 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, 02 Feb 2012 13:26:23 -0000 On 02/02/12 00:42, Justin Uberti wrote: > http://tools.ietf.org/html/rfc5245, section 15.1: > > and: convey transport addresses related to the > candidate, useful for diagnostics and other purposes. > and MUST be present for server reflexive, peer > reflexive, and relayed candidates. If a candidate is server or > peer reflexive, and are equal to the base > for that server or peer reflexive candidate. If the candidate is > relayed, and is equal to the mapped address > in the Allocate response that provided the client with that > relayed candidate (seeAppendix B.3 for a discussion of its > purpose). If the candidate is a host candidate, and > MUST be omitted. > > > > Clearly we don't want to send out the base address when doing TURN-only, but according to the spec, rel-addr/rel-port must be supplied. What's the right way to handle this? > > Justin, the TURN Allocate Response from the TURN server should contain a STUN attribute called XOR-MAPPED-ADDRESS which should contain the IP/port as seen by the TURN server, i.e. the public WAN address of your home router. you should use this IP/port as your rel-addr/rel-port for your Relayed candidate. /alfred From martin.thomson@gmail.com Thu Feb 2 08:57: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 78D0C21F854F for ; Thu, 2 Feb 2012 08:57:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.799 X-Spam-Level: X-Spam-Status: No, score=-4.799 tagged_above=-999 required=5 tests=[AWL=-1.800, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fh5ZOGjr0g7h for ; Thu, 2 Feb 2012 08:57:57 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id B188121F8548 for ; Thu, 2 Feb 2012 08:57:56 -0800 (PST) Received: by bkbzt4 with SMTP id zt4so2582439bkb.31 for ; Thu, 02 Feb 2012 08:57:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=7VJg4fVtAHyZuhI7bzlga/NLu96hDTzhBgzd4QZIoLM=; b=vlmAG9zqCpZEdcDF+yeFn6ebTKf4fFt9C5HzZdPH03qbUKxn3eC8aXELXswmg26SaT vDQ5av9LvFJ2NZ0S4Sig6Y+l/RBjGAaBSBhtO6wTOC8g2ztFvbcDnFdozJmhjlPkYy8S FQOe2MobbBTDcZLw2UtUHK4ZjCCN1LovkbCMg= MIME-Version: 1.0 Received: by 10.204.152.201 with SMTP id h9mr1709040bkw.105.1328201875812; Thu, 02 Feb 2012 08:57:55 -0800 (PST) Received: by 10.204.241.81 with HTTP; Thu, 2 Feb 2012 08:57:55 -0800 (PST) In-Reply-To: <4F2A8EFB.2080308@db.org> References: <4F2A8EFB.2080308@db.org> Date: Thu, 2 Feb 2012 08:57:55 -0800 Message-ID: From: Martin Thomson To: "Alfred E. Heggestad" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] ICE with only TURN candidates: what should rel-addr/rel-port be? 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, 02 Feb 2012 16:57:57 -0000 On 2 February 2012 05:26, Alfred E. Heggestad wrote: > On 02/02/12 00:42, Justin Uberti wrote: >> >> =C2=A0 =C2=A0 =C2=A0 and =C2=A0MUST be present for server refl= exive, peer >> =C2=A0 =C2=A0 =C2=A0 reflexive, and relayed candidates. =C2=A0>> Clearly= we don't want to send out the base address when doing TURN-only, >> but according to the spec, rel-addr/rel-port must be supplied. What's th= e >> right way to handle this? I don't see a big problem here. The text only says that _iff_ you include a reflexive address, you must include IP+port. Obviously, if we are doing TURN only, then omit the candidates you don't want to reveal. > the TURN Allocate Response from the TURN server should contain > a STUN attribute called XOR-MAPPED-ADDRESS The concern is not whether it is possible, but whether it is desirable. Revealing your IP to an as-yet-unaccepted caller has been deemed not to be desirable. --Martin From matthew.kaufman@skype.net Thu Feb 2 09:22: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 A175D21F85A7 for ; Thu, 2 Feb 2012 09:22:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RkW5iq2a1W+N for ; Thu, 2 Feb 2012 09:22:00 -0800 (PST) Received: from AM1EHSOBE004.bigfish.com (am1ehsobe002.messaging.microsoft.com [213.199.154.205]) by ietfa.amsl.com (Postfix) with ESMTP id D7DF421F853E for ; Thu, 2 Feb 2012 09:21:56 -0800 (PST) Received: from mail19-am1-R.bigfish.com (10.3.201.235) by AM1EHSOBE004.bigfish.com (10.3.204.24) with Microsoft SMTP Server id 14.1.225.23; Thu, 2 Feb 2012 17:21:54 +0000 Received: from mail19-am1 (localhost [127.0.0.1]) by mail19-am1-R.bigfish.com (Postfix) with ESMTP id 9067A804FD; Thu, 2 Feb 2012 17:21:55 +0000 (UTC) X-SpamScore: 0 X-BigFish: VS0(zzzz1202hzzz2fh87h2a8h668h839h93fh) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail19-am1: domain of skype.net designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=matthew.kaufman@skype.net; helo=TK5EX14HUBC105.redmond.corp.microsoft.com ; icrosoft.com ; X-FB-DOMAIN-IP-MATCH: fail Received: from mail19-am1 (localhost.localdomain [127.0.0.1]) by mail19-am1 (MessageSwitch) id 1328203313601589_6731; Thu, 2 Feb 2012 17:21:53 +0000 (UTC) Received: from AM1EHSMHS012.bigfish.com (unknown [10.3.201.241]) by mail19-am1.bigfish.com (Postfix) with ESMTP id 8C4CC4C0048; Thu, 2 Feb 2012 17:21:53 +0000 (UTC) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS012.bigfish.com (10.3.207.112) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 2 Feb 2012 17:21:51 +0000 Received: from TK5EX14MBXC274.redmond.corp.microsoft.com ([169.254.3.210]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.02.0247.005; Thu, 2 Feb 2012 09:21:32 -0800 From: Matthew Kaufman To: Martin Thomson , "Alfred E. Heggestad" Thread-Topic: [rtcweb] ICE with only TURN candidates: what should rel-addr/rel-port be? Thread-Index: AQHM4cvW8hPVazod7Ue8+nXNAOoAh5Yp2egw Date: Thu, 2 Feb 2012 17:21:31 +0000 Message-ID: References: <4F2A8EFB.2080308@db.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] ICE with only TURN candidates: what should rel-addr/rel-port be? 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, 02 Feb 2012 17:22:02 -0000 TWFydGluIFRob21zb246DQo+IFRoZSBjb25jZXJuIGlzIG5vdCB3aGV0aGVyIGl0IGlzIHBvc3Np YmxlLCBidXQgd2hldGhlciBpdCBpcyBkZXNpcmFibGUuICBSZXZlYWxpbmcgeW91ciBJUCB0byBh biBhcy15ZXQtdW5hY2NlcHRlZCBjYWxsZXIgaGFzIGJlZW4gZGVlbWVkIG5vdCB0byBiZSBkZXNp cmFibGUuDQoNClRoZSBkZWNpc2lvbiBhYm91dCB3aGV0aGVyIG9yIG5vdCB0byByZXZlYWwgeW91 ciBJUCBiZWZvcmUgY2FsbCBhY2NlcHQgc2hvdWxkIGJlIHVwIHRvIHRoZSB3ZWIgc2VydmVyLg0K DQpBZnRlciBhbGwsIHRoZSB3ZWIgc2VydmVyIGNhbiBhbHJlYWR5IHJldmVhbCB5b3VyIElQIHRv IHRoZSBvdGhlciBzaWRlIGlmIGl0IHdhbnRzIHRvLg0KDQpTaXRlcyB0aGF0IG5lZWQgdG8gcHJv dmlkZSB0aGlzIHByb3RlY3Rpb24gZm9yIGNhbGxpbmcgd2lsbCBkbyBzbywgYnkgYm90aCBub3Qg cmV2ZWFsaW5nIHdoYXQgdGhleSBrbm93IGZyb20gdGhlaXIgSFRUUCBsb2dzICphbmQqIHNlbmRp bmcgZG93biBKYXZhc2NyaXB0IHRoYXQgcHJvdGVjdHMgdGhlIGNhbGxlZCBwYXJ0eSdzIElQIHVu dGlsIGFmdGVyIGNhbGwgYWNjZXB0Lg0KDQpTaXRlcyB0aGF0IGRvbid0IGNhcmUgYW5kIHdhbnQg dG8gcmVkdWNlIHNldHVwIGxhdGVuY3kgd2lsbCBoYXZlIHRoZSBvcHRpb24gdG8gYmVoYXZlIGRp ZmZlcmVudGx5Li4uIHBlcmhhcHMgZm9yIGRpZmZlcmVudCB1c2VycyBldmVuLg0KDQpNYXR0aGV3 IEthdWZtYW4NCg== From petithug@acm.org Thu Feb 2 09:40: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 016F421F863E; Thu, 2 Feb 2012 09:40:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.291 X-Spam-Level: X-Spam-Status: No, score=-102.291 tagged_above=-999 required=5 tests=[AWL=0.309, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUBO01ZDJJlI; Thu, 2 Feb 2012 09:40:11 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 5704621F8634; Thu, 2 Feb 2012 09:40:11 -0800 (PST) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id F369620414; Thu, 2 Feb 2012 17:25:24 +0000 (UTC) Message-ID: <4F2ACA77.6090400@acm.org> Date: Thu, 02 Feb 2012 09:40:07 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120104 Icedove/8.0 MIME-Version: 1.0 To: Behave WG References: <20120202173553.5280.73005.idtracker@ietfa.amsl.com> In-Reply-To: <20120202173553.5280.73005.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.3.4 X-Forwarded-Message-Id: <20120202173553.5280.73005.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: [rtcweb] Fwd: I-D Action: draft-petithuguenin-behave-turn-uris-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: Thu, 02 Feb 2012 17:40:12 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 We sat down over beers in Taipei (thanks Hadriel!) to resolve the differences between the two TURN URIs drafts and agreed on common ground. This new draft merges the best of these two drafts and we are now submitting it to the BEHAVE WG (where the original discussion about TURN URI took place) for consideration. We would like to present this work at the next BEHAVE interim meeting or at any other venue that the chairs would prefer. The reference implementation has been updated and is available at the URL indicated in the draft. - -------- Original Message -------- Subject: I-D Action: draft-petithuguenin-behave-turn-uris-00.txt Date: Thu, 02 Feb 2012 09:35:53 -0800 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers Author(s) : Marc Petit-Huguenin Suhas Nandakumar Gonzalo Salgueiro Paul E. Jones Filename : draft-petithuguenin-behave-turn-uris-00.txt Pages : 13 Date : 2012-02-02 This document specifies the syntax of Uniform Resource Identifier (URI) schemes for the Traversal Using Relays around NAT (TURN) protocol. It defines two URI schemes that can be used to provision the configuration values needed by the resolution mechanism defined in [RFC5928]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-petithuguenin-behave-turn-uris-00.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-petithuguenin-behave-turn-uris-00.txt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJPKspzAAoJECnERZXWan7ERGwQAOqCUDAToY5W2PtXvb8ROfQ1 t8mYB6n2ZWIRWFC5znrvDQ3m5H0BChHh5+C0zUVnRJb8cf33F/ZPISn+nCfpfxRC tAwNbMZ7zxCF6jY0zlpYluMdNJXtzokxiw8qxFKGE+t6yTLZLsFTtR5tBHJuSEj/ Eafm2X+CErrAu2lI4/E2+0NY5+lRUuTmXTVXqKwNspOyGqGW/P8EMX9JY1zx7OqM nxqikwsu+Op6Q8ppXBvIffjDdaHG6uBUPG/7KwM1K7F3EKiRb5pbrxGRRmp7skpU k6LKJISJ3vFSqjyP0fWpc9zA7gri05Qakv2zluYI34ZZI6xiz12Ib768c9FY62l2 9O+5XjP04xvjDNIwdquOzWiexpO9vHjgMBG93KXs3hKyA8dYUsksQtLMj4g5lZrU yKq3OjrfGpHxLwxqYPIflHBQCkzw1vxpaPi20bWCXCEG7og4vKCfNmtzZaPWHdpo Ourfk9oNA36hHHCOBcYhgh2l0/nI6860ATWJfz2KG3NqVb5z/JS2jGDUpqV75le4 rrbdIyvai26xMinC22GTPxww3QQFQF6w+WAj62lZBTvHKe4VZ8XLaMh1POR+zoju 1DruHZgRSGT6jxW92RPat6JEq9fqy7nyYuMhcTckpP1OY52d5ybPxgaeHOYo9bN/ N0657pcM7YN/xpKTSYYX =rozy -----END PGP SIGNATURE----- From ted.ietf@gmail.com Thu Feb 2 11:55: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 A866321F8644 for ; Thu, 2 Feb 2012 11:55:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.429 X-Spam-Level: X-Spam-Status: No, score=-3.429 tagged_above=-999 required=5 tests=[AWL=0.170, 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 TCqKaOGArO94 for ; Thu, 2 Feb 2012 11:55:57 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id C09FA21F8643 for ; Thu, 2 Feb 2012 11:55:52 -0800 (PST) Received: by yhkk25 with SMTP id k25so1520980yhk.31 for ; Thu, 02 Feb 2012 11:55:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=7onA9KTioi4qYzsI1PHSPP9LFv7zhf/C4bw+hxLLt8Y=; b=YVW5m0/7a0nrDwgOxROVnar/ajlpt3Ohnta75+H8wAnLUqhvKrDp5xKj//7hCIES0O S3+djlsPX3SDCIVCkcF/x/LbDO9itsgh3do47oG/W1nfEeo1KTXIS7WkKwZ7xNLwB220 A515Ilu1QgmOXvxVScgVNyNdjQWonsyJ8YhpE= MIME-Version: 1.0 Received: by 10.236.201.201 with SMTP id b49mr6892559yho.18.1328212551262; Thu, 02 Feb 2012 11:55:51 -0800 (PST) Received: by 10.236.103.232 with HTTP; Thu, 2 Feb 2012 11:55:51 -0800 (PST) In-Reply-To: References: <4F2A8EFB.2080308@db.org> Date: Thu, 2 Feb 2012 11:55:51 -0800 Message-ID: From: Ted Hardie To: Matthew Kaufman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] ICE with only TURN candidates: what should rel-addr/rel-port be? 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, 02 Feb 2012 19:55:58 -0000 On Thu, Feb 2, 2012 at 9:21 AM, Matthew Kaufman wrote: > Martin Thomson: >> The concern is not whether it is possible, but whether it is desirable. = =A0Revealing your IP to an as-yet-unaccepted caller has been deemed not to = be desirable. > > The decision about whether or not to reveal your IP before call accept sh= ould be up to the web server. > > After all, the web server can already reveal your IP to the other side if= it wants to. Note that it is not necessarily revealing the same IP as would be used in the call. It's common in some SIP deployments for MobileIP to be used, which results in signaling traffic coming from one address and media traffic coming from another. In the similar case here, the web server may have no idea what IP your media traffic would come through. In the case of a web server running plain HTTP, it is also possible that it only knows the data revealed by any proxies forwarded the traffic. That may or may not include a trustable indication of your real IP. > > Sites that need to provide this protection for calling will do so, by bot= h not revealing what they know from their HTTP logs *and* sending down Java= script that protects the called party's IP until after call accept. > > Sites that don't care and want to reduce setup latency will have the opti= on to behave differently... perhaps for different users even. And the clear UI features you propose to distinguish these cases to end users are? Ted > > Matthew Kaufman > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From martin.thomson@gmail.com Thu Feb 2 13:17: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 3389421F851E for ; Thu, 2 Feb 2012 13:17:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.874 X-Spam-Level: X-Spam-Status: No, score=-4.874 tagged_above=-999 required=5 tests=[AWL=-1.275, 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 PNI7eARHHI0w for ; Thu, 2 Feb 2012 13:17:24 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7741521F8513 for ; Thu, 2 Feb 2012 13:17:24 -0800 (PST) Received: by bkbzt4 with SMTP id zt4so2808108bkb.31 for ; Thu, 02 Feb 2012 13:17:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nafA9krQxDc8VahMG2lmnjCrZiciSJnAzqd7oWoJkOQ=; b=uaISBNS29zU93cAtyX5N+y0fXrGHdvca2+ZqVhZxhvtBCwOSxEh0bpYT2dk2W1lqYK s4BDjLj99TjBFAAxnJCM/m9Dg3waEklKzBNeOTBzkw69CP7eOxlb8Qbxxlik74E5QtXZ RMp2i9Zwef2KXiLPz4ekFk/8HBSMU8mZY4Nio= MIME-Version: 1.0 Received: by 10.204.130.129 with SMTP id t1mr2228005bks.33.1328217442305; Thu, 02 Feb 2012 13:17:22 -0800 (PST) Received: by 10.204.241.81 with HTTP; Thu, 2 Feb 2012 13:17:22 -0800 (PST) In-Reply-To: References: <4F2A8EFB.2080308@db.org> Date: Thu, 2 Feb 2012 13:17:22 -0800 Message-ID: From: Martin Thomson To: Matthew Kaufman Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] ICE with only TURN candidates: what should rel-addr/rel-port be? 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, 02 Feb 2012 21:17:25 -0000 On 2 February 2012 09:21, Matthew Kaufman wrote: > The decision about whether or not to reveal your IP before call accept should be up to the web server. Since the signalling effectively passes through the server, the server has this control. Signing the candidates is the only thing that might prevent this, but - as we discussed - doing so doesn't buy much for the cost that it imposes. > After all, the web server can already reveal your IP to the other side if it wants to. Assuming of course that there are no HTTP intermediaries. And that (as Ted notes), the media is going to follow the same path. --Martin From zachary.zeltsan@alcatel-lucent.com Thu Feb 2 14:20: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 0514B21F8665 for ; Thu, 2 Feb 2012 14:20:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BiQbx-htBHli for ; Thu, 2 Feb 2012 14:20:38 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id F3ED721F8664 for ; Thu, 2 Feb 2012 14:20:37 -0800 (PST) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q12MKaP7020006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 2 Feb 2012 16:20:36 -0600 (CST) 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 q12MKSV8022216 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 2 Feb 2012 16:20:36 -0600 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Thu, 2 Feb 2012 16:20:31 -0600 From: "Zeltsan, Zachary (Zachary)" To: "'Eric Rescorla'" , "'rtcweb@ietf.org'" Date: Thu, 2 Feb 2012 16:20:28 -0600 Thread-Topic: [rtcweb] Generic IdP doc posted Thread-Index: AczaONvZgM3CrbiLS3qHObvtXm3V9gHtT/PQ Message-ID: <5710F82C0E73B04FA559560098BF95B1250CFFCD08@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> 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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [rtcweb] Generic IdP doc posted 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, 02 Feb 2012 22:20:39 -0000 Eric, At the yesterday's call I had a couple of questions regarding your presenta= tion on RTCWEB identity service. (The audio was not good, so I am asking using email). Section 4 (draft-rescorla-rtcweb-generic-idp) explains that a browser need = to instantiate an IdP proxy for interactions with an IdP. According to Figure 1, there are connections between Bob's (B) browser and = IdP A, and between Alice's (A) browser and IdP B. Question 1:=20 Is it a correct assumption that Bob's browser need to instantiate two diffe= rent proxies -- one for interacting with Bob's IdP B and another for inter= acting with Alice's IdP A? (A question regarding the Alice's browser is sim= ilar). The diagram in section 5.5.2 (OAuth example) depicts the interactions betwe= en Alice's browser and IdP, and Bob's browser and IdP. Question 2:=20 Does the diagram show the IdP A? The draft states "similarly, Bob's PeerConnection instantiates an IFRAME to= talk to the IdP". Should not the Bob's PeerConnection instantiate two IFRAME's -- one for tal= king to IdP A and another for talking to IdP B? Wit thanks, Zachary Zeltsan =20 -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Eric Rescorla Sent: Monday, January 23, 2012 8:38 PM To: rtcweb@ietf.org Subject: [rtcweb] Generic IdP doc posted Since Taipei, I have spent a bunch of time working through the details of how to make generic IdP-based authentication work for WebRTC calls. This was very handwavy in Taipei but I believe I now have solutions that will work for all the major issues (which isn't to say that there isn't much left to improve), but this is still at the individual submission stage. The draft is at: http://tools.ietf.org/html/draft-rescorla-rtcweb-generic-idp-00 Comments welcome. I have a prototype implementation of most of the basic concepts (though in JS rather than integrated with the browser), so I hope to have something (though probably something clunky) to demo next week. Best, -Ekr _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From ekr@rtfm.com Thu Feb 2 14:31: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 2C85521F869E for ; Thu, 2 Feb 2012 14:31:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.907 X-Spam-Level: X-Spam-Status: No, score=-102.907 tagged_above=-999 required=5 tests=[AWL=0.070, 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 OJsTrf79S1p8 for ; Thu, 2 Feb 2012 14:31:49 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3922A21F8690 for ; Thu, 2 Feb 2012 14:31:45 -0800 (PST) Received: by vbbfr13 with SMTP id fr13so2333230vbb.31 for ; Thu, 02 Feb 2012 14:31:44 -0800 (PST) Received: by 10.52.72.83 with SMTP id b19mr391789vdv.24.1328221900117; Thu, 02 Feb 2012 14:31:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.71.19 with HTTP; Thu, 2 Feb 2012 14:30:59 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: <5710F82C0E73B04FA559560098BF95B1250CFFCD08@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <5710F82C0E73B04FA559560098BF95B1250CFFCD08@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> From: Eric Rescorla Date: Thu, 2 Feb 2012 14:30:59 -0800 Message-ID: To: "Zeltsan, Zachary (Zachary)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Generic IdP doc posted 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, 02 Feb 2012 22:31:50 -0000 On Thu, Feb 2, 2012 at 2:20 PM, Zeltsan, Zachary (Zachary) wrote: > Eric, > > At the yesterday's call I had a couple of questions regarding your presen= tation on RTCWEB identity service. > (The audio was not good, so I am asking using email). No worries. Thanks for writing. > Section 4 (draft-rescorla-rtcweb-generic-idp) explains that a browser nee= d to instantiate an IdP proxy for interactions with an IdP. > According to Figure 1, there are connections between Bob's (B) browser an= d IdP A, and between Alice's (A) browser and IdP B. > Question 1: > Is it a correct assumption that Bob's browser need to instantiate two dif= ferent proxies -- =A0one for interacting with Bob's IdP B and another for i= nteracting with Alice's IdP A? (A question regarding the Alice's browser is= similar). Yes. One might imagine that you could get away with only one if they were t= he same IdP, but if you're using WebIntents (which seems increasingly likely) then you would get two proxies by default. > The diagram in section 5.5.2 (OAuth example) depicts the interactions bet= ween Alice's browser and IdP, and Bob's browser and IdP. > Question 2: > Does the diagram show the IdP A? > The draft states "similarly, Bob's PeerConnection instantiates an IFRAME = to talk to the IdP". > Should not the Bob's PeerConnection instantiate two IFRAME's -- one for t= alking to IdP A and another for talking to IdP B? Yep. Best, -Ekr From jonathan@vidyo.com Thu Feb 2 15:40:55 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 781AF21F86BB; Thu, 2 Feb 2012 15:40:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4h9kC1YfG7p; Thu, 2 Feb 2012 15:40:54 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id C75D521F86B9; Thu, 2 Feb 2012 15:40:53 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id E8F6F7E3D38; Thu, 2 Feb 2012 18:40:52 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB025.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 0CF597E3976; Thu, 2 Feb 2012 18:40:48 -0500 (EST) Received: from BE235.mail.lan ([10.110.32.235]) by HUB025.mail.lan ([10.110.17.25]) with mapi; Thu, 2 Feb 2012 18:40:33 -0500 From: Jonathan Lennox To: Justin Uberti Date: Thu, 2 Feb 2012 18:40:46 -0500 Thread-Topic: [rtcweb] ICE with only TURN candidates: what should rel-addr/rel-port be? Thread-Index: AcziBBaVWV6DXGQ8R5eNZLT6plxFJw== Message-ID: <607A2845-E8A6-4C66-BA1A-619E1B471B7C@vidyo.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_607A2845E8A64C66BA1A619E1B471B7Cvidyocom_" MIME-Version: 1.0 Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [rtcweb] ICE with only TURN candidates: what should rel-addr/rel-port be? 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, 02 Feb 2012 23:40:55 -0000 --_000_607A2845E8A64C66BA1A619E1B471B7Cvidyocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think this should be an issue for the mmusic group, not rtcweb -- it appl= ies to anything that's doing ICE candidates in SDP. I suggest replies just= go to the mmusic mailing list. On Feb 1, 2012, at 3:42 PM, Justin Uberti wrote: http://tools.ietf.org/html/rfc5245, section 15.1: and : convey transport addresses related to the candidate, useful for diagnostics and other purposes. and MUST be present for server reflexive, peer reflexive, and relayed candidates. If a candidate is server or peer reflexive, and are equal to the base for that server or peer reflexive candidate. If the candidate is relayed, and is equal to the mapped address in the Allocate response that provided the client with that relayed candidate (see Appendix B.3 for a discussion of its purpose). If the candidate is a host candidate, and MUST be omitted. Clearly we don't want to send out the base address when doing TURN-only, bu= t according to the spec, rel-addr/rel-port must be supplied. What's the rig= ht way to handle this? For clarity (since the followups on the RTCWeb mailing list indicated some = confusion): the use case is an endpoint which, for location privacy reasons= , wants to offer only TURN candidates in its set of ICE candidates, so the = remote ICE peer doesn't know its actual network location. (The standard ex= ample is the woman calling from the battered women's shelter.) The problem is that RFC 5245 says you MUST include your mapped (server-refl= exive) address when encoding relayed (TURN) candidates in SDP. If you do th= is, however, it completely breaks location privacy -- the mapped address is= exactly what you're trying to hide. It wouldn't be too hard to pick a known-invalid IP and port -- 0.0.0.0 0, p= resumably -- to encode in this situation (so as not to break strict parsers= ). The question is whether this would break any endpoints that are trying t= o follow the behavior in Appendix B.3 of RFC 5245, i.e. trying to apply QoS= rules for the path between the endpoint and the TURN server. -- Jonathan Lennox jonathan@vidyo.com --_000_607A2845E8A64C66BA1A619E1B471B7Cvidyocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I think this should b= e an issue for the mmusic group, not rtcweb -- it applies to anything that'= s doing ICE candidates in SDP.  I suggest replies just go to the mmusi= c mailing list.

On Feb 1, 2012, at 3:42 PM, Justin= Uberti wrote:

http://tools.ietf.org/html/rfc5245=
, section 15.1:      
      <rel-addr> and=
 <rel-port>:  convey transport addresses related to the
      candidate, useful for diagnostics and other purposes. <rel-addr>=
;
      and <rel-port> MUST be present for server reflexive, peer
      reflexive, and relayed candidates.  If a candidate is server or
      peer reflexive, <rel-addr> and <rel-port> are equal to th=
e base
      for that server or peer reflexive candidate.  If the candidate is
      relayed, <rel-addr> and <rel-port> is equal to the mapped=
 address
      in the Allocate response that provided the client with that
      relayed candidate (see Appendix B.3 for a discussion of its
      purpose).  If the candidate is a host candidate, <rel-addr> and
      <rel-port> MUST be omitted.

Clearly we don't want to send o=
ut the base address when doing TURN-only, but according to the spec, rel-ad=
dr/rel-port must be supplied. What's the right way to handle this?


For clarity (since the =
followups on the RTCWeb mailing list indicated some confusion): the use cas=
e is an endpoint which, for location privacy reasons, wants to offer only T=
URN candidates in its set of ICE candidates, so the remote ICE peer doesn't=
 know its actual network location.  (The standard example is the woman=
 calling from the battered women's shelter.)

The p=
roblem is that RFC 5245 says you MUST include your mapped (server-reflexive=
) address when encoding relayed (TURN) candidates in SDP. If you do this, h=
owever, it completely breaks location privacy -- the mapped address is exac=
tly what you're trying to hide.

It wouldn't = be too hard to pick a known-invalid IP and port -- 0.0.0.0 0, presumably --= to encode in this situation (so as not to break strict parsers). The quest= ion is whether this would break any endpoints that are trying to follow the= behavior in Appendix B.3 of RFC 5245, i.e. trying to apply QoS rules for t= he path between the endpoint and the TURN server.

--
Jonathan Lennox
jonathan@vidyo.com

= --_000_607A2845E8A64C66BA1A619E1B471B7Cvidyocom_-- From randell-ietf@jesup.org Thu Feb 2 20:13:19 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 92B0021F85D6 for ; Thu, 2 Feb 2012 20:13:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.18 X-Spam-Level: X-Spam-Status: No, score=-1.18 tagged_above=-999 required=5 tests=[AWL=-1.040, BAYES_20=-0.74, 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 cNQB4a0+tvQN for ; Thu, 2 Feb 2012 20:13:18 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id CFE1A21F8581 for ; Thu, 2 Feb 2012 20:13:18 -0800 (PST) Received: from pool-173-49-135-74.phlapa.fios.verizon.net ([173.49.135.74] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RtAWT-0003in-Vi for rtcweb@ietf.org; Thu, 02 Feb 2012 22:13:18 -0600 Message-ID: <4F2B5E84.90909@jesup.org> Date: Thu, 02 Feb 2012 23:11:48 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F29D2A6.4090802@ericsson.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] Confirming consensus from Interim: Data protocol and security mechanism 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, 03 Feb 2012 04:13:19 -0000 On 2/1/2012 11:20 PM, Yoshifumi Nishida wrote: > Hello, > > On Wed, Feb 1, 2012 at 4:02 PM, Magnus Westerlund > wrote: >> >> The seconds consensus call was on the order of SCTP and DTLS on top of >> UDP. The two alternatives are: SCTP/DTLS/UDP or DTLS/SCTP/UDP. This was >> a unanimous consensus, where 18 preferred SCTP/DTLS/UDP, and no for the >> other order. Does the WG participants not present agrees or objects? > > This is not an objection. I'm just curious.. > If we think about the situation where we want to use SCTP without UDP > encaps, DTLS/SCTP/UDP seems to be more straightforward approach to me. > Also, we already have RFC6083. > I'm wondering why there was no support for this. 1) DTLS/SCTP gives up several features or adds limitations: a) Max datagram size b) Can't do reliable streams without another stream layer on top c) Extra call setup time even when not using data channels etc 2) WebRTC is not speced to be used except over ICE+UDP 3) Strong assertion by an SCTP RFC author that SCTP/DTLS is straightforward/easy (no surprise) and a good choice. As described, it was not a controversial decision in the room after a fair bit of discussion. -- Randell Jesup randell-ietf@jesup.org From randell-ietf@jesup.org Thu Feb 2 20:42: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 5CA7711E8072 for ; Thu, 2 Feb 2012 20:42:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[AWL=-0.660, BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oL-oCgOrNjgT for ; Thu, 2 Feb 2012 20:42:27 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id C4E4D11E8071 for ; Thu, 2 Feb 2012 20:42:27 -0800 (PST) Received: from pool-173-49-135-74.phlapa.fios.verizon.net ([173.49.135.74] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RtAyh-0004yQ-2F for rtcweb@ietf.org; Thu, 02 Feb 2012 22:42:27 -0600 Message-ID: <4F2B6558.7050900@jesup.org> Date: Thu, 02 Feb 2012 23:40:56 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F2A8EFB.2080308@db.org> 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] ICE with only TURN candidates: what should rel-addr/rel-port be? 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, 03 Feb 2012 04:42:28 -0000 On 2/2/2012 2:55 PM, Ted Hardie wrote: > On Thu, Feb 2, 2012 at 9:21 AM, Matthew Kaufman > wrote: >> Martin Thomson: >>> The concern is not whether it is possible, but whether it is desirable. Revealing your IP to an as-yet-unaccepted caller has been deemed not to be desirable. >> >> The decision about whether or not to reveal your IP before call accept should be up to the web server. >> >> After all, the web server can already reveal your IP to the other side if it wants to. > > Note that it is not necessarily revealing the same IP as would be used > in the call. It's common in some SIP deployments for MobileIP to be > used, which results in signaling traffic coming from one address and > media traffic coming from another. In the similar case here, the web > server may have no idea what IP your media traffic would come through. True, though the security concern is more (though not entirely) that your physical location would be (partially) exposed by your IP address, as geolocation-by-IP does expose quite a bit of information (and in a specific case would expose that you're hiding with your Aunt Matilda in Boise, for example). Right now, if someone gets a disposable cellphone, their location is fairly safe against either (former) abusers and against (say) people you're hiding from (witness protection, etc). Allowing IP exposure will allow people to be at least roughly located in many cases, and finely with access to various databases (I believe) - and as pointed out, just knowing the town/city can be a significant information leak. > In the case of a web server running plain HTTP, it is also possible > that it only knows the data revealed by any proxies forwarded the > traffic. That may or may not include a trustable indication of your > real IP. Yes, though pure-HTTP is advised against - though a proxy might expose similar partial-location info. >> Sites that need to provide this protection for calling will do so, by both not revealing what they know from their HTTP logs *and* sending down Javascript that protects the called party's IP until after call accept. >> >> Sites that don't care and want to reduce setup latency will have the option to behave differently... perhaps for different users even. > > And the clear UI features you propose to distinguish these cases to > end users are? That's the primary flaw in Matthew's comment in my mind. And as we said, (almost all) users a) don't really understand all the security mumbo-jumbo (if they even know it exists), and b) users don't change defaults. IMHO: We can decide we don't care about the location-privacy issue, decide we want it by default (and live with limitations), or decide we want to make it possible but not the default (even though most people who might benefit from it would likely never find/understand it). -- Randell Jesup randell-ietf@jesup.org From martin.thomson@gmail.com Fri Feb 3 08:37: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 D46C321F84EA; Fri, 3 Feb 2012 08:36:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.732 X-Spam-Level: X-Spam-Status: No, score=-4.732 tagged_above=-999 required=5 tests=[AWL=-1.133, 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 9cmUYC5+LNNa; Fri, 3 Feb 2012 08:36:49 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id ACE2821F84FB; Fri, 3 Feb 2012 08:36:48 -0800 (PST) Received: by bkbzt4 with SMTP id zt4so3562900bkb.31 for ; Fri, 03 Feb 2012 08:36:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UA24DPfoASDYD/lwjtWh+g3+VO/0CE/YpNTeBEZjZ2I=; b=sFALA87Ni6aaio+9Ikdw/5JEGxpeV2IIlyoQUmtC2BPY3lBX5Pqk/paxkvr2xqSstl HecpsSYqZkeOIk6v8+bQjPOIh+Gc0QrUzWNsEiO3nLVGfma51ToHPV742JTQqwogU8B0 l1XfKGM8CBRu1rXVbBZ8pcQo4J9vPySvClEKg= MIME-Version: 1.0 Received: by 10.204.130.129 with SMTP id t1mr3904804bks.33.1328287007746; Fri, 03 Feb 2012 08:36:47 -0800 (PST) Received: by 10.204.241.81 with HTTP; Fri, 3 Feb 2012 08:36:47 -0800 (PST) In-Reply-To: <607A2845-E8A6-4C66-BA1A-619E1B471B7C@vidyo.com> References: <607A2845-E8A6-4C66-BA1A-619E1B471B7C@vidyo.com> Date: Fri, 3 Feb 2012 08:36:47 -0800 Message-ID: From: Martin Thomson To: Jonathan Lennox Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [rtcweb] ICE with only TURN candidates: what should rel-addr/rel-port be? 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, 03 Feb 2012 16:37:03 -0000 On 2 February 2012 15:40, Jonathan Lennox wrote: > (The standard > example is the woman calling from the battered women's shelter.) The other way round, actually. The case is where someone knows how to contact the woman (by webrtc) and simply by attempting to make the call, they obtain her location. > The problem is that RFC 5245 says you MUST include your mapped > (server-reflexive) address when encoding relayed (TURN) candidates in SDP. I don't think that's true from reading the text more carefully. What the text says is that if you include a server reflexive address, you must include rel-addr and rel-port. Section 15.1 describes the grammar, not the usage. There is no reason that you can't simply omit all candidates other than the "relay" candidates. --Martin From ted.ietf@gmail.com Fri Feb 3 09:00: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 5E6CB21F8574 for ; Fri, 3 Feb 2012 09:00:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.437 X-Spam-Level: X-Spam-Status: No, score=-4.437 tagged_above=-999 required=5 tests=[AWL=1.162, BAYES_00=-2.599, GB_I_INVITATION=-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 AiBfulifKAW6 for ; Fri, 3 Feb 2012 09:00:00 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA7521F8555 for ; Fri, 3 Feb 2012 09:00:00 -0800 (PST) Received: by ghbg16 with SMTP id g16so2063818ghb.31 for ; Fri, 03 Feb 2012 09:00:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=xL53eC9fVZ1BDj84jnKanI4xMWXsTavJ3vvMb7Az28c=; b=Va+xgR69m+tVihZXcsn+v1P1HU1j4wJ8Do2s0eCmHAewn08OO6Bq0g1NBuRsihJlB/ kodjHbTXizqGnsJ0vq/bCbQXIHACXMWx1J3mOrtY7VbGFCchQX8J5AeWCJfrtmOZzCLM PD92YApcYCcUHL64W54kSckVQlABvS+uUnFJk= MIME-Version: 1.0 Received: by 10.101.151.9 with SMTP id d9mr3789554ano.17.1328288400240; Fri, 03 Feb 2012 09:00:00 -0800 (PST) Received: by 10.236.103.232 with HTTP; Fri, 3 Feb 2012 09:00:00 -0800 (PST) In-Reply-To: <4F2B6558.7050900@jesup.org> References: <4F2A8EFB.2080308@db.org> <4F2B6558.7050900@jesup.org> Date: Fri, 3 Feb 2012 09:00:00 -0800 Message-ID: From: Ted Hardie To: Randell Jesup Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] ICE with only TURN candidates: what should rel-addr/rel-port be? 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, 03 Feb 2012 17:00:01 -0000 On Thu, Feb 2, 2012 at 8:40 PM, Randell Jesup wrot= e: > On 2/2/2012 2:55 PM, Ted Hardie wrote: >=A0In the similar case here, the web >> server may have no idea what IP your media traffic would come through. > > > True, though the security concern is more (though not entirely) that your > physical location would be (partially) exposed by your IP address, as > geolocation-by-IP does expose quite a bit of information (and in a specif= ic > case would expose that you're hiding with your Aunt Matilda in Boise, for > example). > > Right now, if someone gets a disposable cellphone, their location is fair= ly > safe against either (former) abusers and against (say) people you're hidi= ng > from (witness protection, etc). =A0Allowing IP exposure will allow people= to > be at least roughly located in many cases, and finely with access to vari= ous > databases (I believe) - and as pointed out, just knowing the town/city ca= n > be a significant information leak. > This is true, but not the point I was making. I was pointing out that the web server having access to *an* IP address does not necessarily mean it has access to the IP address that would be used for media. If both IP addresses are equally revealing of location, then the distinction for physical location may not be important for some use cases, but I believe revealing two IP addresses is worse privacy-wise than one. More importantly, it is a reason not to cede control over the decision to reveal this data to the web server/app writer. The information already revealed to them may not be the same. I think the larger point has already been by Martin, though, in that what we're trying to do is avoid revealing the media address of a called party until the call has been accepted. If we don't do that, then an unsolicited "call" (invitation to hangout, facebook video chat request, in-game trash talk attempt) could reveal the IP address of the party who will ultimately decline. That's the privacy implication we *must* deal with. I personally think that the best way forward may be to provide equal protection to the party *placing* the call, simply because having a setting that says "I'm okay/not okay with revealing my media IP to people I'm trying to talk to before they agree to the call" will get buried very far down a preference stack and will be confusing to a large set of folks (at best, they'll understand it by analogy to Caller-ID blocking, which already has surprising results if you dial 1-800 numbers etc.). But the trade-offs are a little different there, and I understand that others may disagree. regards, Ted From jonathan@vidyo.com Fri Feb 3 09:27: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 1965F21F8533; Fri, 3 Feb 2012 09:27:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C27+YtSPjqjU; Fri, 3 Feb 2012 09:27:15 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5F521F84F7; Fri, 3 Feb 2012 09:27:15 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id B89057E3C57; Fri, 3 Feb 2012 12:27:14 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB028.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 4AC927E3D5C; Fri, 3 Feb 2012 12:27:14 -0500 (EST) Received: from BE235.mail.lan ([10.110.32.235]) by HUB028.mail.lan ([10.110.17.28]) with mapi; Fri, 3 Feb 2012 12:27:13 -0500 From: Jonathan Lennox To: Martin Thomson Date: Fri, 3 Feb 2012 12:27:13 -0500 Thread-Topic: [rtcweb] ICE with only TURN candidates: what should rel-addr/rel-port be? Thread-Index: AczimRFvWXdvOBLxTsKrh3eZuevSfQ== Message-ID: <9173BA4F-51E7-4F27-958F-6E4DAD0C17F9@vidyo.com> References: <607A2845-E8A6-4C66-BA1A-619E1B471B7C@vidyo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [rtcweb] ICE with only TURN candidates: what should rel-addr/rel-port be? 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, 03 Feb 2012 17:27:16 -0000 On Feb 3, 2012, at 11:36 AM, Martin Thomson wrote: > On 2 February 2012 15:40, Jonathan Lennox wrote: >> (The standard >> example is the woman calling from the battered women's shelter.) >=20 > The other way round, actually. The case is where someone knows how to > contact the woman (by webrtc) and simply by attempting to make the > call, they obtain her location. Right, good point. But *why* you want location privacy isn't really relevant to the discussion= here -- there are lots of use cases and reasons to want it. >> The problem is that RFC 5245 says you MUST include your mapped >> (server-reflexive) address when encoding relayed (TURN) candidates in SD= P. >=20 > I don't think that's true from reading the text more carefully. What > the text says is that if you include a server reflexive address, you > must include rel-addr and rel-port. Section 15.1 describes the > grammar, not the usage. There is no reason that you can't simply omit > all candidates other than the "relay" candidates. Read the next sentence -- if you include a relay candidate, you must includ= e "the mapped address in the Allocate response that provided the client wit= h that relayed candidate" as the rel-addr and rel-port. This is the same as= the server-reflexive address. =20 -- Jonathan Lennox jonathan@vidyo.com From martin.thomson@gmail.com Fri Feb 3 09:41: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 89A1821F8528; Fri, 3 Feb 2012 09:41:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.619 X-Spam-Level: X-Spam-Status: No, score=-4.619 tagged_above=-999 required=5 tests=[AWL=-1.020, 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 bPQOECzXBGNH; Fri, 3 Feb 2012 09:41:05 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id A5AC021F84D4; Fri, 3 Feb 2012 09:41:04 -0800 (PST) Received: by bkbzt4 with SMTP id zt4so3621123bkb.31 for ; Fri, 03 Feb 2012 09:41:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=hnToKbFP4bH2zdYpCl+HSKJZgu/kx4udT2tbWNB7i/Y=; b=x2dUxhvi+CdLJNltffW8QEB7jSyPDq91ZihPekYrY3jYU/eD0BKxAB64eV5ZSM6sND Q6VBr2XNE6Kzwi9z8zGoC7p7Er0oXkuvkTdETCY5+ZMit8td42vV51GTJ/CCab1HBEoW Lep43D6IoQqpU7lCVZk7/BukqYeUnIWbXuQKI= MIME-Version: 1.0 Received: by 10.204.130.129 with SMTP id t1mr4030404bks.33.1328290863784; Fri, 03 Feb 2012 09:41:03 -0800 (PST) Received: by 10.204.241.81 with HTTP; Fri, 3 Feb 2012 09:41:03 -0800 (PST) In-Reply-To: <9173BA4F-51E7-4F27-958F-6E4DAD0C17F9@vidyo.com> References: <607A2845-E8A6-4C66-BA1A-619E1B471B7C@vidyo.com> <9173BA4F-51E7-4F27-958F-6E4DAD0C17F9@vidyo.com> Date: Fri, 3 Feb 2012 09:41:03 -0800 Message-ID: From: Martin Thomson To: Jonathan Lennox Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [rtcweb] ICE with only TURN candidates: what should rel-addr/rel-port be? 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, 03 Feb 2012 17:41:05 -0000 On 3 February 2012 09:27, Jonathan Lennox wrote: > Read the next sentence -- if you include a relay candidate, you must incl= ude "the mapped address in the Allocate response that provided the client w= ith that relayed candidate" as the rel-addr and rel-port. This is the same = as the server-reflexive address. My bad. Your suggestion of ":: 0" should do to satisfy syntax checkers. From randell-ietf@jesup.org Fri Feb 3 10:39: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 4C7A521F854C for ; Fri, 3 Feb 2012 10:39:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.282 X-Spam-Level: X-Spam-Status: No, score=-3.282 tagged_above=-999 required=5 tests=[AWL=1.317, BAYES_00=-2.599, GB_I_INVITATION=-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 4p5lChtAr8D0 for ; Fri, 3 Feb 2012 10:39:35 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id C5BF221F8540 for ; Fri, 3 Feb 2012 10:39:35 -0800 (PST) Received: from pool-173-49-135-74.phlapa.fios.verizon.net ([173.49.135.74] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RtO2o-00047o-Ve for rtcweb@ietf.org; Fri, 03 Feb 2012 12:39:35 -0600 Message-ID: <4F2C298C.1050500@jesup.org> Date: Fri, 03 Feb 2012 13:38:04 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F2A8EFB.2080308@db.org> <4F2B6558.7050900@jesup.org> 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] ICE with only TURN candidates: what should rel-addr/rel-port be? 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, 03 Feb 2012 18:39:36 -0000 On 2/3/2012 12:00 PM, Ted Hardie wrote: > On Thu, Feb 2, 2012 at 8:40 PM, Randell Jesup wrote: > I think the larger point has already been by Martin, though, in that > what we're trying to do is avoid revealing the media address of a > called party until the call has been accepted. If we don't do that, > then an unsolicited "call" (invitation to hangout, facebook video chat > request, in-game trash talk attempt) could reveal the IP address of > the party who will ultimately decline. That's the privacy implication > we *must* deal with. Absolutely. > I personally think that the best way forward may be to provide equal > protection to the party *placing* the call, simply because having a > setting that says "I'm okay/not okay with revealing my media IP to > people I'm trying to talk to before they agree to the call" will get > buried very far down a preference stack and will be confusing to a > large set of folks (at best, they'll understand it by analogy to > Caller-ID blocking, which already has surprising results if you dial > 1-800 numbers etc.). But the trade-offs are a little different > there, and I understand that others may disagree. That is the closest commonly-known analog; the problem with that is that the analogy breaks down for the callee (people don't expect to have information leaked about them if they're called, except maybe that their phone is off or out of range). But it's likely the best we can use to help explain it to users. I'd have no problem with a UI (or API for that matter) that tied the two sides (outgoing and incoming location privacy). The problem in my mind is the defaults, and how these options would be visible to the user (though that is largely an app issue, but we/W3C may want to give guidance). -- Randell Jesup randell-ietf@jesup.org From randell-ietf@jesup.org Fri Feb 3 11:21: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 E31F421F851E for ; Fri, 3 Feb 2012 11:21:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[AWL=0.229, 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 ql77mE-9t-MS for ; Fri, 3 Feb 2012 11:21:10 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 8BCCE21F84FF for ; Fri, 3 Feb 2012 11:20:56 -0800 (PST) Received: from pool-173-49-135-74.phlapa.fios.verizon.net ([173.49.135.74] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RtOgp-0001ZV-QH; Fri, 03 Feb 2012 13:20:55 -0600 Message-ID: <4F2C333C.9010400@jesup.org> Date: Fri, 03 Feb 2012 14:19:24 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F29BD31.9040700@ericsson.com> <0f8c01cce137$16a477f0$43ed67d0$@com> In-Reply-To: <0f8c01cce137$16a477f0$43ed67d0$@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: Cc: Randall Stewart Subject: [rtcweb] Continuing consent validation 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, 03 Feb 2012 19:21:11 -0000 If we require WebRTC-enabled gateways to connect to "legacy" devices/gateways, then continuing consent is something that could be dealt with via an SCTP HEARTBEAT, instead of un-authenticated STUN connectivity checks. This would require an SCTP association to be created at each PeerConnection connection, but the SCTP handshake probably could be backgrounded and not slow down the connection process. (We'll probably want that backgrounding of SCTP handshake anyways, in order to open media channels ASAP.) This of course only handles continuing consent (and keeping the port propped open) only in the case of a native PeerConnection connection, not any form of interop to "legacy" devices, and having a second mechanism may not make sense if we end up connecting directly, so this ties into the DTLS-SRTP vs SDES vs plain-RTP discussion. If the answer is DTLS-SRTP, then we have to decide if we expect to be able to talk to a non-WebRTC client that supports DTLS-SRTP (and ICE) directly. If the answer is "only directly to WebRTC clients", then this is a good option; if the answer is not that (or if SDES/plain RTP is needed), then this could not be the only mechanism, which reduces the utility (though perhaps not to zero). There's a minor plus to having the association already created if we want to add data channels, but that's quite minor. Just a thought while reading SCTP specs... -- Randell Jesup randell-ietf@jesup.org From matthew.kaufman@skype.net Fri Feb 3 11:21: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 AC97021F85EA; Fri, 3 Feb 2012 11:21:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WwvXmNJU6xzh; Fri, 3 Feb 2012 11:21:47 -0800 (PST) Received: from AM1EHSOBE006.bigfish.com (am1ehsobe004.messaging.microsoft.com [213.199.154.207]) by ietfa.amsl.com (Postfix) with ESMTP id 6B59E21F8505; Fri, 3 Feb 2012 11:21:46 -0800 (PST) Received: from mail39-am1-R.bigfish.com (10.3.201.240) by AM1EHSOBE006.bigfish.com (10.3.204.26) with Microsoft SMTP Server id 14.1.225.23; Fri, 3 Feb 2012 19:21:42 +0000 Received: from mail39-am1 (localhost [127.0.0.1]) by mail39-am1-R.bigfish.com (Postfix) with ESMTP id 9D926E0598; Fri, 3 Feb 2012 19:21:45 +0000 (UTC) X-SpamScore: 0 X-BigFish: VS0(zzzz1202hzzz2fh87h2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail39-am1: domain of skype.net designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=matthew.kaufman@skype.net; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; X-FB-DOMAIN-IP-MATCH: fail Received: from mail39-am1 (localhost.localdomain [127.0.0.1]) by mail39-am1 (MessageSwitch) id 1328296903293595_22713; Fri, 3 Feb 2012 19:21:43 +0000 (UTC) Received: from AM1EHSMHS002.bigfish.com (unknown [10.3.201.242]) by mail39-am1.bigfish.com (Postfix) with ESMTP id 4107B400045; Fri, 3 Feb 2012 19:21:43 +0000 (UTC) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS002.bigfish.com (10.3.207.102) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 3 Feb 2012 19:21:40 +0000 Received: from TK5EX14MBXC274.redmond.corp.microsoft.com ([169.254.3.210]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0247.005; Fri, 3 Feb 2012 11:21:28 -0800 From: Matthew Kaufman To: Martin Thomson , Jonathan Lennox Thread-Topic: [rtcweb] ICE with only TURN candidates: what should rel-addr/rel-port be? Thread-Index: AQHM4pIZRQ4Lrz8npESGkc635yvt2pYrjA6w Date: Fri, 3 Feb 2012 19:21:28 +0000 Message-ID: References: <607A2845-E8A6-4C66-BA1A-619E1B471B7C@vidyo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [rtcweb] ICE with only TURN candidates: what should rel-addr/rel-port be? 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, 03 Feb 2012 19:21:51 -0000 Martin Thomson: > other way round, actually. The case is where someone knows how to contac= t the woman (by webrtc) and simply by attempting to make the call, they > obtain her location. Exactly. So the woman must use a webrtc provider who 1) doesn't reveal her = IP address to bad people itself and 2) doesn't set the parameters such that= her local or STUN address is sent prior to answer. Requiring the browser t= o *never* be able to provide the STUN or local address before answering is = overkill (and providers who want faster connections will circumvent by buil= ding a brief null call and figuring it out that way). >> The problem is that RFC 5245 says you MUST include your mapped >> (server-reflexive) address when encoding relayed (TURN) candidates in SD= P. >I don't think that's true from reading the text more carefully. What the = text says is that if you include a server reflexive address, you must inclu= de rel-addr > and rel-port. Section 15.1 describes the grammar, not the usage. There = is no reason that you can't simply omit all candidates other than the "rela= y" > candidates. That's how I read it too. Pretty clear you could return *no* candidates, if that's appropriate. Matthew Kaufman From martin.thomson@gmail.com Fri Feb 3 11:44: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 5492B21F85C2 for ; Fri, 3 Feb 2012 11:44:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.526 X-Spam-Level: X-Spam-Status: No, score=-4.526 tagged_above=-999 required=5 tests=[AWL=-0.927, 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 Qm1glrn9vNj8 for ; Fri, 3 Feb 2012 11:44:25 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9984821F8574 for ; Fri, 3 Feb 2012 11:44:25 -0800 (PST) Received: by bkbzt4 with SMTP id zt4so3720333bkb.31 for ; Fri, 03 Feb 2012 11:44:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2zgucOghzusj6CedH82FmYgudKsjnGuUjYx5e6px4Jc=; b=uriuBJxSMnlYZQmfD0KMbXX/X0lqexQluARvQIc3Cb1AaXMgLX+cX77gE+aEfVfaOR d1M1g9nGiPbclsUZfATumMBAqoxKWz6epN+l/VHXuQEkHABOxodV+1F+WmmG4YdErCxf QS/Psp9x1BiHDnZ8E1WwjK/06Ksl6dravxEOs= MIME-Version: 1.0 Received: by 10.204.153.195 with SMTP id l3mr4186012bkw.123.1328298264393; Fri, 03 Feb 2012 11:44:24 -0800 (PST) Received: by 10.204.241.81 with HTTP; Fri, 3 Feb 2012 11:44:24 -0800 (PST) In-Reply-To: <4F2C333C.9010400@jesup.org> References: <4F29BD31.9040700@ericsson.com> <0f8c01cce137$16a477f0$43ed67d0$@com> <4F2C333C.9010400@jesup.org> Date: Fri, 3 Feb 2012 11:44:24 -0800 Message-ID: From: Martin Thomson To: Randell Jesup Content-Type: text/plain; charset=UTF-8 Cc: rtcweb@ietf.org, Randall Stewart Subject: Re: [rtcweb] Continuing consent validation 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, 03 Feb 2012 19:44:26 -0000 On 3 February 2012 11:19, Randell Jesup wrote: > continuing consent is something that could be dealt > with via an SCTP HEARTBEAT I don't see why you would want to create a data channel without having been asked for one. And the cost of supporting the data channel on a legacy gateway that isn't using the data stream seems a little excessive. --Martin From Michael.Tuexen@lurchi.franken.de Fri Feb 3 11:57: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 ACF6821F8619 for ; Fri, 3 Feb 2012 11:57:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWquaQMJze6K for ; Fri, 3 Feb 2012 11:57:51 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id B081A21F8618 for ; Fri, 3 Feb 2012 11:57:50 -0800 (PST) Received: from [192.168.1.103] (p5481A8F7.dip.t-dialin.net [84.129.168.247]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 3C6391C0C0BD9; Fri, 3 Feb 2012 20:57:48 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Michael Tuexen In-Reply-To: <4F2C333C.9010400@jesup.org> Date: Fri, 3 Feb 2012 20:57:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <61CD20E7-4CE7-4756-8827-BC6A0AFC77FA@lurchi.franken.de> References: <4F29BD31.9040700@ericsson.com> <0f8c01cce137$16a477f0$43ed67d0$@com> <4F2C333C.9010400@jesup.org> To: Randell Jesup X-Mailer: Apple Mail (2.1257) Cc: rtcweb@ietf.org, Randall Stewart Subject: Re: [rtcweb] Continuing consent validation 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, 03 Feb 2012 19:57:51 -0000 On Feb 3, 2012, at 8:19 PM, Randell Jesup wrote: > If we require WebRTC-enabled gateways to connect to "legacy" = devices/gateways, then continuing consent is something that could be = dealt with via an SCTP HEARTBEAT, instead of un-authenticated STUN = connectivity checks. This would require an SCTP association to be = created at each PeerConnection connection, but the SCTP handshake = probably could be backgrounded and not slow down the connection process. >=20 > (We'll probably want that backgrounding of SCTP handshake anyways, in = order to open media channels ASAP.) >=20 > This of course only handles continuing consent (and keeping the port = propped open) only in the case of a native PeerConnection connection, = not any form of interop to "legacy" devices, and having a second = mechanism may not make sense if we end up connecting directly, so this = ties into the DTLS-SRTP vs SDES vs plain-RTP discussion. If the answer = is DTLS-SRTP, then we have to decide if we expect to be able to talk to = a non-WebRTC client that supports DTLS-SRTP (and ICE) directly. If the = answer is "only directly to WebRTC clients", then this is a good option; = if the answer is not that (or if SDES/plain RTP is needed), then this = could not be the only mechanism, which reduces the utility (though = perhaps not to zero). >=20 > There's a minor plus to having the association already created if we = want to add data channels, but that's quite minor. >=20 > Just a thought while reading SCTP specs... ... or you could use DTLS HEARTBEATS as specified in http://tools.ietf.org/html/draft-ietf-tls-dtls-heartbeat-04 which is currently in AUTH48 and implemented in OpenSSL 1.0.1 (currently = in beta2). This does not require the setup of a DATA channel, but does only work if = you have DTLS. So it applies to DTLS-SRTP, not to SDES. On the other hand, I agree: Setting up the SCTP association as soon as = possible, minimizes the setup time of the data channel. Maybe another issue (I'm not that familiar with media transport = (especially video): Does the media channel need path MTU discovery? It is clear that this is = needed by the data channel and SCTP provides it. But how is it done if it is = needed also by the media channel? Best regards Michael >=20 > --=20 > Randell Jesup > randell-ietf@jesup.org > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From caryfitz@employees.org Fri Feb 3 12:23: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 49AC021F84CF for ; Fri, 3 Feb 2012 12:23:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 Jm-X2FhnuoNs for ; Fri, 3 Feb 2012 12:23:25 -0800 (PST) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id 4B08C21F8504 for ; Fri, 3 Feb 2012 12:23:25 -0800 (PST) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id CAA395D2C; Fri, 3 Feb 2012 12:23:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=ivsqB0QPuC9m6XU/MNhGyMC9vtY=; b= luISrkIDGykEV55CKiYI3nrpTmMJqmP9Rb7URmJ7tLT3lewKpVSG/Ax8pIcN/3Wo AalYbMEAez/RkrRLYdb2HGnTc2nG3TqWOUOowBbKsz4r3CsndgWkLz1wZNzKgUVA ny7N2dze9FvsEoX91wvjR60gvRq5vquJ4OwCaiz3lJU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=GmZ8lRcctjk7bLorarW18FWI+3 sDq314QEJMf/HtYod2eAOidfXYWYsv30+GrCZ8mcGdxOuPEVMX1QsaRUU3N5L/h5 UQCbj8VGjcwvbkBOjgzcCFowLqxliuad7q147U7mDmeWgeButCCupNYSi3+TSHl9 KGtOdqf32CMHTmYRo= Received: from [10.0.0.53] (unknown [198.144.216.227]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: caryfitz) by banjo.employees.org (Postfix) with ESMTPSA id 114935D1B; Fri, 3 Feb 2012 12:23:24 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_65E60CDE-E057-40B5-A4DE-D76BA233D745" From: Cary W FitzGerald In-Reply-To: <4F288752.1080307@alvestrand.no> Date: Fri, 3 Feb 2012 12:23:24 -0800 Message-Id: <27AA2F02-FF13-4ABC-B9CE-810BC34AF52D@employees.org> References: <4F288752.1080307@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1251.1) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] JSEP terminology 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, 03 Feb 2012 20:23:26 -0000 --Apple-Mail=_65E60CDE-E057-40B5-A4DE-D76BA233D745 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I think that the term was invented not long after dirt was discovered, = so its real origins may be obscure. But I imagine that it derives from = the notion of a NxN matrix of TDM channels where any participant on one = axis could be connected with one or more participants on the other axis. = While not a plane, the analogy is planar. If you'll pardon a bit of heresy, if you set aside multicast (as the = VoIP community has largely done), then I submit for almost everything = we've done in VoIP, "media circuit" is just as descriptive as "media = path/stream". Cheerfully accepting flames, Cary. On Jan 31, 2012, at 4:29 PM, Harald Alvestrand wrote: > On 01/30/2012 12:07 PM, Henry Sinnreich wrote: >>=20 >> Here is just a nit to an otherwise true groundbreaking and quite = frankly, IMHO long overdue and refreshing approach and it=92s about = terminology. >>=20 >> What is the =93media plane=94 (par 4.3)? Does it have two dimensions = and if yes, what are they? >> IMO there are many other terms that are better suited, such as =93media= streams=94, etc. >> =20 >> As is, the =93media plane=94 terminology is just a reminder of = certain legacy =93control planes=94 that should remain here unnamed :-) > I like "media path", mostly because there's already a definition in = section 2.4 of draft-ietf-rtcweb-overview, so I don't have to trot out = another definition :-) >=20 > Harald >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail=_65E60CDE-E057-40B5-A4DE-D76BA233D745 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I = think that the term was invented not long after dirt was discovered, so = its real origins may be obscure.  But I imagine that it derives = from the notion of a NxN matrix of TDM channels where any participant on = one axis could be connected with one or more participants on the other = axis.  While not a plane, the analogy is = planar.

If you'll pardon a bit of heresy, if you set = aside multicast (as the VoIP community has largely done), then I submit = for almost everything we've done in VoIP, "media circuit" is just as = descriptive as "media path/stream".

Cheerfully = accepting = flames,

Cary.

On Jan = 31, 2012, at 4:29 PM, Harald Alvestrand wrote:

=20 =20
On 01/30/2012 12:07 PM, Henry Sinnreich wrote:
JSEP terminology Here is just a nit to an otherwise true groundbreaking and quite frankly, IMHO long overdue and refreshing approach and it=92s about terminology.

What is the =93media plane=94 (par 4.3)? Does it have two dimensions and if yes, what are they?
IMO there are many other terms that are better suited, such as =93media streams=94, etc.
 
As is, the =93media plane=94 terminology is just a reminder of certain legacy =93control planes=94 that should remain here unnamed :-)
I like "media path", mostly because there's already a definition in section 2.4 of draft-ietf-rtcweb-overview, so I don't have to trot out another definition :-)

=             &n= bsp; Harald

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

= --Apple-Mail=_65E60CDE-E057-40B5-A4DE-D76BA233D745-- From stewe@stewe.org Fri Feb 3 12:34: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 67D7111E8088 for ; Fri, 3 Feb 2012 12:34:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CgTW4gSlgz9J for ; Fri, 3 Feb 2012 12:34:33 -0800 (PST) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id 4FBEE11E8074 for ; Fri, 3 Feb 2012 12:34:30 -0800 (PST) Received: from [10.167.48.124] (unverified [65.91.55.117]) by stewe.org (SurgeMail 3.9e) with ESMTP id 234-1743317 for ; Fri, 03 Feb 2012 21:34:21 +0100 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Fri, 03 Feb 2012 12:34:15 -0800 From: Stephan Wenger To: "rtcweb@ietf.org" Message-ID: Thread-Topic: [rtcweb] Confirming consensus from Interim: Data protocol and security mechanism In-Reply-To: <4F29D2A6.4090802@ericsson.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Originating-IP: 65.91.55.117 X-Authenticated-User: stewe@stewe.org Subject: Re: [rtcweb] Confirming consensus from Interim: Data protocol and security mechanism 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, 03 Feb 2012 20:34:34 -0000 Hi chairs, Is there a reason why these two consensus calls are being reconfirmed on the list, whereas the ROAP/JSEP consensus call is not reconfirmed (unless I missed the email). In the jabber transcript, this call is around 23:20, and the consensus appeared to me to be considerably weaker than in the two calls below... Thanks, Stephan On 2.1.2012 16:02 , "Magnus Westerlund" wrote: >WG, > >This is a 2 week call for confirming the consensus of the interim >meeting regarding data transport. The WG members not present at the >interim are requested to indicate support or objections on the consensus >from the interim. This email contains two calls related to the data >transport. Please provide any input no later than the 15th of February. > >The jabber logs are pretty well capturing the discussion. Please see >from 00:18:36 in >http://www.ietf.org/jabber/logs/rtcweb/2012-02-01.html > >The first consensus call made was which transport protocol that should >be used. Based on the discussion it was clear that SCTP was favored and >that was confirmed by the consensus call. Where 19 participants >preferred SCTP as the transport protocol for the data channel and 3 >desired something else. The WG declared clear consensus for using SCTP >as the transport protocol for data. Does the WG participants not present >agrees or objects? > >The seconds consensus call was on the order of SCTP and DTLS on top of >UDP. The two alternatives are: SCTP/DTLS/UDP or DTLS/SCTP/UDP. This was >a unanimous consensus, where 18 preferred SCTP/DTLS/UDP, and no for the >other order. Does the WG participants not present agrees or objects? > >Cheers > >Magnus Westerlund > >---------------------------------------------------------------------- >Multimedia Technologies, Ericsson Research EAB/TVM >---------------------------------------------------------------------- >Ericsson AB | Phone +46 10 7148287 >F=E4r=F6gatan 6 | Mobile +46 73 0949079 >SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >---------------------------------------------------------------------- > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From juberti@google.com Fri Feb 3 12: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 5765821F85C9 for ; Fri, 3 Feb 2012 12:45:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.724 X-Spam-Level: X-Spam-Status: No, score=-102.724 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100, WEIRD_PORT=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 K0wGs8CxQ5Ly for ; Fri, 3 Feb 2012 12:45:53 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id CCEB921F85AD for ; Fri, 3 Feb 2012 12:45:53 -0800 (PST) Received: by ggnq2 with SMTP id q2so2472709ggn.31 for ; Fri, 03 Feb 2012 12:45:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:x-system-of-record:content-type; bh=gNBqz+EgT/hmkSZqfYJdm+4oEqKOoK6otqwUUCtZAgo=; b=jhncuUZm3iuV4hn2of5/5ltjbNzm/FDD5Kff5CIAXpEOZSmgfgQj4uZCQ8OcDULXO8 lrQMD/iTzMZA4JVDSP/hgWSWO6xuBBrIOBDZFXRMHkfq3zcxQHVpmXTnB+843cXo+RHG p/DCXZkSDbssh2beKTJPYxN5AQSR4wjiyytnE= Received: by 10.50.89.196 with SMTP id bq4mr10214770igb.26.1328301953367; Fri, 03 Feb 2012 12:45:53 -0800 (PST) Received: by 10.50.89.196 with SMTP id bq4mr10214763igb.26.1328301953292; Fri, 03 Feb 2012 12:45:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.85.132 with HTTP; Fri, 3 Feb 2012 12:45:33 -0800 (PST) In-Reply-To: References: <607A2845-E8A6-4C66-BA1A-619E1B471B7C@vidyo.com> <9173BA4F-51E7-4F27-958F-6E4DAD0C17F9@vidyo.com> From: Justin Uberti Date: Fri, 3 Feb 2012 12:45:33 -0800 Message-ID: To: Martin Thomson X-System-Of-Record: true Content-Type: multipart/alternative; boundary=e89a8f3ba68114992604b8156609 Cc: Jonathan Lennox , "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [rtcweb] ICE with only TURN candidates: what should rel-addr/rel-port be? 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, 03 Feb 2012 20:45:54 -0000 --e89a8f3ba68114992604b8156609 Content-Type: text/plain; charset=UTF-8 On Fri, Feb 3, 2012 at 9:41 AM, Martin Thomson wrote: > On 3 February 2012 09:27, Jonathan Lennox wrote: > > Read the next sentence -- if you include a relay candidate, you must > include "the mapped address in the Allocate response that provided the > client with that relayed candidate" as the rel-addr and rel-port. This is > the same as the server-reflexive address. > > My bad. Your suggestion of ":: 0" should do to satisfy syntax checkers. > Thanks for the replies. Since the text in Appendix B.3 that Jonathan referred to indicates that rel-addr/port is not critical to ICE operation, 0.0.0.0:0 sounds good to me. --e89a8f3ba68114992604b8156609 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Feb 3, 2012 at 9:41 AM, Martin Thomson <= span dir=3D"ltr"><martin.tho= mson@gmail.com> wrote:
On 3 February 2012 09:27, Jonathan Lennox <jonathan@vidyo.com> wrote:
> Read the next sentence -- if you include a relay candidate, you must i= nclude "the mapped address in the Allocate response that provided the = client with that relayed candidate" as the rel-addr and rel-port. This= is the same as the server-reflexive address.

My bad. =C2=A0Your suggestion of ":: 0" should do to satisf= y syntax checkers.

Thanks for the replies. Since the text in Appen= dix B.3 that Jonathan referred to indicates that rel-addr/port is not criti= cal to ICE operation, 0.0.0.0:0 sounds goo= d to me.
--e89a8f3ba68114992604b8156609-- From ted.ietf@gmail.com Fri Feb 3 13:28: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 6593621F84B8 for ; Fri, 3 Feb 2012 13:28:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.49 X-Spam-Level: X-Spam-Status: No, score=-3.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 CwJgmlntsuyl for ; Fri, 3 Feb 2012 13:28:19 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id C5DDF21F84B4 for ; Fri, 3 Feb 2012 13:28:19 -0800 (PST) Received: by ghbg16 with SMTP id g16so2219277ghb.31 for ; Fri, 03 Feb 2012 13:28:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Z2jxCRH00vv5fhTVucM85JCb2gXY0ksbojvJuIszJS8=; b=vS3UHs6iyH/oUYxJ73YUFWNBzmfl9WM6T9HGuISHmthtKZywhInPeYtLyqWoBzdDmr 08Fkz6G9VnNqS0SFAwgasfSkaSuqjAV5XCLMmt5o4ARrCc0hji0e939B64PfX+/FYvOq Pz9abdRgRFipOzY6uqHyXJsWom+MjUH1ZU7JI= MIME-Version: 1.0 Received: by 10.236.145.2 with SMTP id o2mr14520760yhj.1.1328304499379; Fri, 03 Feb 2012 13:28:19 -0800 (PST) Received: by 10.236.103.232 with HTTP; Fri, 3 Feb 2012 13:28:19 -0800 (PST) In-Reply-To: References: <4F29D2A6.4090802@ericsson.com> Date: Fri, 3 Feb 2012 13:28:19 -0800 Message-ID: From: Ted Hardie To: Stephan Wenger Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Confirming consensus from Interim: Data protocol and security mechanism 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, 03 Feb 2012 21:28:20 -0000 Hi Stephan, We want to be very careful in how we put the ROAP/JSEP-related consensus call to the list, but please be assured it will be confirmed on the list. Ted On Fri, Feb 3, 2012 at 12:34 PM, Stephan Wenger wrote: > Hi chairs, > Is there a reason why these two consensus calls are being reconfirmed on > the list, whereas the ROAP/JSEP consensus call is not reconfirmed (unless > I missed the email). =A0In the jabber transcript, this call is around 23:= 20, > and the consensus appeared to me to be considerably weaker than in the tw= o > calls below... > Thanks, > Stephan > > > On 2.1.2012 16:02 , "Magnus Westerlund" > wrote: > >>WG, >> >>This is a 2 week call for confirming the consensus of the interim >>meeting regarding data transport. The WG members not present at the >>interim are requested to indicate support or objections on the consensus >>from the interim. This email contains two calls related to the data >>transport. Please provide any input no later than the 15th of February. >> >>The jabber logs are pretty well capturing the discussion. Please see >>from 00:18:36 in >>http://www.ietf.org/jabber/logs/rtcweb/2012-02-01.html >> >>The first consensus call made was which transport protocol that should >>be used. Based on the discussion it was clear that SCTP was favored and >>that was confirmed by the consensus call. Where 19 participants >>preferred SCTP as the transport protocol for the data channel and 3 >>desired something else. The WG declared clear consensus for using SCTP >>as the transport protocol for data. Does the WG participants not present >>agrees or objects? >> >>The seconds consensus call was on the order of SCTP and DTLS on top of >>UDP. The two alternatives are: SCTP/DTLS/UDP or DTLS/SCTP/UDP. This was >>a unanimous consensus, where 18 preferred SCTP/DTLS/UDP, and no for the >>other order. Does the WG participants not present agrees or objects? >> >>Cheers >> >>Magnus Westerlund >> >>---------------------------------------------------------------------- >>Multimedia Technologies, Ericsson Research EAB/TVM >>---------------------------------------------------------------------- >>Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287 >>F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| 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 > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From ted.ietf@gmail.com Fri Feb 3 14:53: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 C7C1E21F8621; Fri, 3 Feb 2012 14:53:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.563 X-Spam-Level: X-Spam-Status: No, score=-1.563 tagged_above=-999 required=5 tests=[AWL=-1.827, BAYES_00=-2.599, FRT_SOMA=1.664, FRT_SOMA2=2.199, 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 v7l+tvxVtsJ7; Fri, 3 Feb 2012 14:53:59 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 20E8E21F8620; Fri, 3 Feb 2012 14:53:59 -0800 (PST) Received: by ggnq2 with SMTP id q2so2528453ggn.31 for ; Fri, 03 Feb 2012 14:53:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ktjgEg1Sm2KQiyAmEch7K0hHnwIZP2XDeRs5nuYA8wo=; b=cP5mM0ffUn4yZriiZNHdKTkg3S2RlFnz4RxfmXtnt7wNnb1fAlCrzA+g+jhwaUbnyN O83kt5ISbvD27BqAzf5Qauxz8cAkfj/xWfHROaaK6gzNQald/Q2E6V4SCX7wQdbuzMdk Og2ZWTSpoT0ZJ892pHykZvYSB6APe5a6qe+IU= MIME-Version: 1.0 Received: by 10.101.131.20 with SMTP id i20mr4423244ann.29.1328309638715; Fri, 03 Feb 2012 14:53:58 -0800 (PST) Received: by 10.236.103.232 with HTTP; Fri, 3 Feb 2012 14:53:58 -0800 (PST) In-Reply-To: References: <607A2845-E8A6-4C66-BA1A-619E1B471B7C@vidyo.com> Date: Fri, 3 Feb 2012 14:53:58 -0800 Message-ID: From: Ted Hardie To: Matthew Kaufman Content-Type: text/plain; charset=ISO-8859-1 Cc: Jonathan Lennox , "mmusic@ietf.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] ICE with only TURN candidates: what should rel-addr/rel-port be? 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, 03 Feb 2012 22:53:59 -0000 On Fri, Feb 3, 2012 at 11:21 AM, Matthew Kaufman wrote: > > Requiring the browser to *never* be able to provide the STUN or local address before answering is overkill (and providers who want faster connections will circumvent by >building a brief null call and figuring it out that way). > Obviously we can disagree about "overkill" when it comes to the balance between latency and privacy, but before we go there, I want to make sure I understand what you mean by a null call. If I understand the optimization, you're proposing having the downloaded javascript instantiate a session to the server ("call home on download"), so that the server can collect the addresses it uses and then hand them out to any other user who wishes to make a call to the user. If that is the proposal, I have to say that I think it runs directly counter to the privacy imperative we just identified. Let's imagine our vampire friends at deadjournal decide to do this. If I want to find out where the holder of sparklyvamp@deadjournal.com is, er, living, I can set up a script that attempts to autocall them every N minutes and then lookup. Whenever they sign in, deadjournal will collect their IPs and send them over to me for use in my call. sparklyvamp may very well know I am staker, and decide not to answer. In the mean time, however, I'm on my way with holy water, garlic, and a sharpened stick. In order to avoid this fate, sparklyvamp must know whether or not any particular service they use which *might* embed audio and video in some parts of the applications they provide or host will or will not use this. This includes the services deadjournal hosts for Zomga, the well-known undead games maker. Have I misunderstood your optimization? Ted From prvs=3735eb756=tterriberry@mozilla.com Fri Feb 3 15:10: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 3F11B21F8510 for ; Fri, 3 Feb 2012 15:10:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nokxcJh0wc-K for ; Fri, 3 Feb 2012 15:10:33 -0800 (PST) Received: from mxip3i.isis.unc.edu (mxip3i.isis.unc.edu [152.2.2.195]) by ietfa.amsl.com (Postfix) with ESMTP id D48A421F850F for ; Fri, 3 Feb 2012 15:10:32 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EADhoLE+sGgRa/2dsb2JhbABDsC2BcgEBBThAARALGAkWDwkDAgECAUUQAwEHAsBpi1cBBAIBAgIJBAENA4NBGQQDDAMUBVciAoNJBIhEkigTjSI X-IronPort-AV: E=Sophos;i="4.73,353,1325480400"; d="scan'208";a="271829837" Received: from mr2a.isis.unc.edu (HELO smtp.unc.edu) ([172.26.4.90]) by mxip3o.isis.unc.edu with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Feb 2012 18:10:26 -0500 X-UNC-Auth-As: tterribe X-UNC-Auth-IP: 63.245.220.240 Received: from [10.250.5.61] (corp-240.mv.mozilla.com [63.245.220.240]) (authenticated bits=0) by smtp.unc.edu (8.14.4/8.14.3) with ESMTP id q13NAOuY020974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 3 Feb 2012 18:10:25 -0500 (EST) Message-ID: <4F2C6960.7050108@mozilla.com> Date: Fri, 03 Feb 2012 15:10:24 -0800 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0.1) Gecko/20120130 SeaMonkey/2.5 MIME-Version: 1.0 To: public-webrtc@w3.org References: <4F2B8F5A.3050709@ericsson.com> <4F2C1C63.4090602@alvestrand.no> <4F2C1E2E.9070200@ericsson.com> <4F2C568F.8040004@jesup.org> In-Reply-To: <4F2C568F.8040004@jesup.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" , Randall Stewart Subject: Re: [rtcweb] SCTP mapping to data channels 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, 03 Feb 2012 23:10:34 -0000 Randell Jesup wrote: > I'm quite open to alternative ideas, and someone could make a case for > providing a transparent interface to the full set of SCTP functionality. I'm not going to make such a case, but the comment was made during the interim meeting that we don't have use cases and derived requirements for all the features we want from the data channel. I've had at least one that I've been kicking around in my head as various options for handling signaling and channels are discussed, so I would like to propose adding it to the use-cases document (cc'ing the IETF list since it maintains it): Simple video communication with peer-to-peer file transfer This use-case is almost identical to the Simple Video Communication Service use-case (Section 4.2.1). The difference is that during the session, one user drags a directory containing (potentially thousands of) files onto the page, and these are transferred to the other user. The user can select a "high priority transfer" option to lower the quality of the media in order to speed up the file transfer. This motivates the desire for a reliable data channel (the user would like to receive the entire file), that is peer-to-peer (the web server probably doesn't want to pay for all that traffic), doesn't starve the media, and whose relative share of the available bandwidth can be configured (maybe I'm willing to put up with low framerate video as long as the files gets there quickly, maybe I just want the transfer to go in the background so you can look at it when we're done talking). I'm open to suggestions about how exactly to phrase those as requirements. It also has implications, which are not requirements, for how the SCTP channels are used and APIs around them are constructed. The natural (though by no means the only nor the best) way to implement something like this would be to open a unidirectional channel for each file, send all the data for that file, and then close it and proceed to the next file. But this requires that a) the receiving side gets informed of a channel opening, b) before it receives any data on it, and c) the receiving side gets informed of a channel closing, but d) only after it has received all the in-flight data on that channel, and e) channels can later be re-used. a) and c) are needed to delineate the bounds of each file. Because there may be many thousands of tiny files, the latency introduced by a) and c) should be minimized (most file transfer programs have terrible throughput in this case). b) is required to avoid the need for the app to buffer unknown amounts of incoming data before it has any idea what it is or what it's for. d) is needed to make sure the app knows when it has all the data for a file and can close it. b) and d) may be complicated if the channel open/close notifications are done via signaling in the SDP, rather than over the SCTP association somehow (though that doesn't mean they're impossible). e) is necessary because I can (almost certainly) add more files to my directory than any pre-set maximum number of channels you pick, though I only ever need to use one or two channels simultaneously. It may also argue the need for a label that is not the same as the SCTP channel number. In this case, something containing the file path from the sender might be a particularly useful label. You could argue that all five of these things could be achieved with a single ordered, reliable data channel and a one-off custom protocol. But if the webapp needs to resort to that even in this simple case, then I'd argue that providing an API for multiple independent channels isn't adding much value. From martin.thomson@gmail.com Fri Feb 3 15:39: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 8384D21F84FB; Fri, 3 Feb 2012 15:39:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.449 X-Spam-Level: X-Spam-Status: No, score=-4.449 tagged_above=-999 required=5 tests=[AWL=-0.850, 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 8EJDQ0JN+BiX; Fri, 3 Feb 2012 15:39:52 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id D82A221F84D9; Fri, 3 Feb 2012 15:39:51 -0800 (PST) Received: by bkbzt4 with SMTP id zt4so3860214bkb.31 for ; Fri, 03 Feb 2012 15:39:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=5H6r6H/RuVAxYbILh9F1cg6vhIQgaZrLgcY2ZH8A9H0=; b=ideSvCcHd+JjfqobSVq3UVvpMXqwZBRApDN2Xb8VfNNvzWx/1aVVOKxx8tGtShs0F+ qzjl9WZ4YlSH2IjSx6PNTNJesZN6xHfO+Xcg9xReZboElyUQ77Vx1mWqLc4VaTEoZOyx s3f95bVCOpFxFve5npPUeJU6Dru3hGwZ+Tkfw= MIME-Version: 1.0 Received: by 10.204.152.26 with SMTP id e26mr4326722bkw.87.1328312390971; Fri, 03 Feb 2012 15:39:50 -0800 (PST) Received: by 10.204.241.81 with HTTP; Fri, 3 Feb 2012 15:39:50 -0800 (PST) In-Reply-To: References: <607A2845-E8A6-4C66-BA1A-619E1B471B7C@vidyo.com> Date: Fri, 3 Feb 2012 15:39:50 -0800 Message-ID: From: Martin Thomson To: Ted Hardie Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Jonathan Lennox , "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [rtcweb] ICE with only TURN candidates: what should rel-addr/rel-port be? 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, 03 Feb 2012 23:39:53 -0000 On 3 February 2012 14:53, Ted Hardie wrote: > Obviously we can disagree about "overkill" when it comes to the > balance between latency and privacy, but before we go there, I want to > make sure I understand what you mean by a null call. =C2=A0If I understan= d > the optimization, you're proposing having the downloaded javascript > instantiate a session to the server ("call home on download"), so that > the server can collect the addresses it uses and then hand them out to > any other user who wishes to make a call to the user. The point is that, at some level, the user has to trust the site they are visiting before they grant the site access to PeerConnection. It _is_ possible to keep the server ignorant with a little trickery. You use this new data bearer to exchange candidates and keep all but relay candidates from the server, or always use your own TURN server and always relay. The exchange of candidates would have to be standardized though. Keep in mind that you also need to proxy your HTTP traffic to the server as well. That's the trade-off, and maybe that's an option that should remain on the table, but you can see where "overkill" comes from. --Martin From roman@telurix.com Fri Feb 3 15:55: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 3CCBB21F8534; Fri, 3 Feb 2012 15:55:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.803 X-Spam-Level: X-Spam-Status: No, score=-2.803 tagged_above=-999 required=5 tests=[AWL=0.173, 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 4kMS1OnlO7QO; Fri, 3 Feb 2012 15:55:44 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 983F421F851A; Fri, 3 Feb 2012 15:55:44 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so244742pbc.31 for ; Fri, 03 Feb 2012 15:55:44 -0800 (PST) Received: by 10.68.239.41 with SMTP id vp9mr22345498pbc.17.1328313344294; Fri, 03 Feb 2012 15:55:44 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id i10sm16502713pbg.10.2012.02.03.15.55.41 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 03 Feb 2012 15:55:42 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so244699pbc.31 for ; Fri, 03 Feb 2012 15:55:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.209.39 with SMTP id mj7mr21682918pbc.25.1328313340575; Fri, 03 Feb 2012 15:55:40 -0800 (PST) Received: by 10.68.40.232 with HTTP; Fri, 3 Feb 2012 15:55:40 -0800 (PST) In-Reply-To: References: <607A2845-E8A6-4C66-BA1A-619E1B471B7C@vidyo.com> Date: Fri, 3 Feb 2012 18:55:40 -0500 Message-ID: From: Roman Shpount To: Martin Thomson Content-Type: multipart/alternative; boundary=14dae9c09e06d0bfa204b8180c16 Cc: Jonathan Lennox , "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [rtcweb] ICE with only TURN candidates: what should rel-addr/rel-port be? 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, 03 Feb 2012 23:55:45 -0000 --14dae9c09e06d0bfa204b8180c16 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Feb 3, 2012 at 6:39 PM, Martin Thomson wrote: > The point is that, at some level, the user has to trust the site they > are visiting before they grant the site access to PeerConnection. > > It _is_ possible to keep the server ignorant with a little trickery. > You use this new data bearer to exchange candidates and keep all but > relay candidates from the server, or always use your own TURN server > and always relay. The exchange of candidates would have to be > standardized though. Keep in mind that you also need to proxy your > HTTP traffic to the server as well. That's the trade-off, and maybe > that's an option that should remain on the table, but you can see > where "overkill" comes from. > > I thought that TURN servers would be provisioned by the java script (web site) and not the end user, or do we plan to provide an interface in web browser settings that allows the overwrite for this? One more thing that an end user can do to ensure privacy, is to always require to use a proxy. I am not sure if the decision have been made, if proxy is required to be used, if specified by the end user. One option is that if proxy is specified, the only candidate used would be a TURN address obtained via a TCP or TLS connection established through proxy. Unfortunately, this exactly the opposite of what you would want to do, if you were trying to optimize the media for best performance, since in this case you would try to connect to the TURN server directly even if proxy is specified (and to use reflective or local IP if possible). Final consideration is that even if such options are provided in a web browser, very few users would be educated enough to use them properly. _____________ Roman Shpount --14dae9c09e06d0bfa204b8180c16 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Feb 3, 2012 at 6:39 PM= , Martin Thomson <martin.thomson@gmail.com> wrote:
The point is that, at some level, the user has to trust the site they
are visiting before they grant the site access to PeerConnection.

It _is_ possible to keep the server ignorant with a little trickery.
You use this new data bearer to exchange candidates and keep all but
relay candidates from the server, or always use your own TURN server
and always relay. =A0The exchange of candidates would have to be
standardized though. =A0Keep in mind that you also need to proxy your
HTTP traffic to the server as well. =A0That's the trade-off, and maybe<= br> that's an option that should remain on the table, but you can see
where "overkill" comes from.


I thought that TURN servers would be provisioned= by the java script (web site) and not the end user, or do we plan to provi= de an interface in web browser settings that allows the overwrite for this?=

One more thing that an end user can do to ensure privacy, is to always = require to use a proxy. I am not sure if the decision have been made, if pr= oxy is required to be used, if specified by the end user. One option is tha= t if proxy is specified, the only candidate used would be a TURN address ob= tained via a TCP or TLS connection established through proxy. Unfortunately= , this exactly the opposite of what you would want to do, if you were tryin= g to optimize the media for best performance, since in this case you would = try to connect to the TURN server directly even if proxy is specified (and = to use reflective or local IP if possible).

Final consideration is that even if such options are provided in a web = browser, very few users would be educated enough to use them properly.
_= ____________
Roman Shpount


--14dae9c09e06d0bfa204b8180c16-- From stefan.lk.hakansson@ericsson.com Sat Feb 4 06:14: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 9A8CB21F851B for ; Sat, 4 Feb 2012 06:14:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.964 X-Spam-Level: X-Spam-Status: No, score=-8.964 tagged_above=-999 required=5 tests=[AWL=1.635, 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 oiC626F1A5z0 for ; Sat, 4 Feb 2012 06:14:14 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 7487621F84D8 for ; Sat, 4 Feb 2012 06:14:13 -0800 (PST) X-AuditID: c1b4fb3d-b7b26ae000000a35-ca-4f2d3d34b866 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id B2.0C.02613.43D3D2F4; Sat, 4 Feb 2012 15:14:12 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Sat, 4 Feb 2012 15:14:11 +0100 Message-ID: <4F2D3D32.3010309@ericsson.com> Date: Sat, 4 Feb 2012 15:14:10 +0100 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F2B8F5A.3050709@ericsson.com> <4F2C1C63.4090602@alvestrand.no> <4F2C1E2E.9070200@ericsson.com> <4F2C568F.8040004@jesup.org> <4F2C6960.7050108@mozilla.com> In-Reply-To: <4F2C6960.7050108@mozilla.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] SCTP mapping to data channels 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, 04 Feb 2012 14:14:14 -0000 On 02/04/2012 12:10 AM, Timothy B. Terriberry wrote: > Randell Jesup wrote: >> I'm quite open to alternative ideas, and someone could make a case for >> providing a transparent interface to the full set of SCTP functionality. > > I'm not going to make such a case, but the comment was made during the > interim meeting that we don't have use cases and derived requirements > for all the features we want from the data channel. I've had at least > one that I've been kicking around in my head as various options for > handling signaling and channels are discussed, so I would like to > propose adding it to the use-cases document (cc'ing the IETF list since > it maintains it): > > > > Simple video communication with peer-to-peer file transfer > > This use-case is almost identical to the Simple Video Communication > Service use-case (Section 4.2.1). The difference is that during the > session, one user drags a directory containing (potentially thousands > of) files onto the page, and these are transferred to the other user. > The user can select a "high priority transfer" option to lower the > quality of the media in order to speed up the file transfer. > > > > This motivates the desire for a reliable data channel (the user would > like to receive the entire file), that is peer-to-peer (the web server > probably doesn't want to pay for all that traffic), doesn't starve the > media, and whose relative share of the available bandwidth can be > configured (maybe I'm willing to put up with low framerate video as long > as the files gets there quickly, maybe I just want the transfer to go in > the background so you can look at it when we're done talking). I'm open > to suggestions about how exactly to phrase those as requirements. > > It also has implications, which are not requirements, for how the SCTP > channels are used and APIs around them are constructed. The natural > (though by no means the only nor the best) way to implement something > like this would be to open a unidirectional channel for each file, send > all the data for that file, and then close it and proceed to the next > file. But this requires that a) the receiving side gets informed of a > channel opening, b) before it receives any data on it, and c) the > receiving side gets informed of a channel closing, but d) only after it > has received all the in-flight data on that channel, and e) channels can > later be re-used. > > a) and c) are needed to delineate the bounds of each file. Because there > may be many thousands of tiny files, the latency introduced by a) and c) > should be minimized (most file transfer programs have terrible > throughput in this case). > > b) is required to avoid the need for the app to buffer unknown amounts > of incoming data before it has any idea what it is or what it's for. d) > is needed to make sure the app knows when it has all the data for a file > and can close it. b) and d) may be complicated if the channel open/close > notifications are done via signaling in the SDP, rather than over the > SCTP association somehow (though that doesn't mean they're impossible). > > e) is necessary because I can (almost certainly) add more files to my > directory than any pre-set maximum number of channels you pick, though I > only ever need to use one or two channels simultaneously. It may also > argue the need for a label that is not the same as the SCTP channel > number. In this case, something containing the file path from the sender > might be a particularly useful label. > > You could argue that all five of these things could be achieved with a > single ordered, reliable data channel and a one-off custom protocol. But > if the webapp needs to resort to that even in this simple case, then I'd > argue that providing an API for multiple independent channels isn't > adding much value. If I understand things correctly, each file would be represented by a blob object. So with the API Justin has proposed, with the addition of the send(blob) (or with the API I proposed as well for that matter), the app would just have to send each of those blobs. If the developer sends them over one single channel, or opens several parallel is up to her/him, but either way there would be no need to open/close, or to in any way handle file start/stop - each file would be represented by a discrete object, and the app just sends them. I assume that in this use case the html input element with type file (and multiple attribute set) would be used so that the user can select the files, > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From randell-ietf@jesup.org Sat Feb 4 10:48: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 212FE21F8478 for ; Sat, 4 Feb 2012 10:48:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.384 X-Spam-Level: X-Spam-Status: No, score=-2.384 tagged_above=-999 required=5 tests=[AWL=0.215, 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 Z1qKyKU4pCTw for ; Sat, 4 Feb 2012 10:48:38 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 97A9B21F8473 for ; Sat, 4 Feb 2012 10:48:38 -0800 (PST) Received: from pool-173-49-135-74.phlapa.fios.verizon.net ([173.49.135.74] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Rtkf7-0003cq-SV for rtcweb@ietf.org; Sat, 04 Feb 2012 12:48:37 -0600 Message-ID: <4F2D7D26.1030807@jesup.org> Date: Sat, 04 Feb 2012 13:47:02 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F2B8F5A.3050709@ericsson.com> <4F2C1C63.4090602@alvestrand.no> <4F2C1E2E.9070200@ericsson.com> <4F2C568F.8040004@jesup.org> <4F2C6960.7050108@mozilla.com> <4F2D3D32.3010309@ericsson.com> In-Reply-To: <4F2D3D32.3010309@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] SCTP mapping to data channels 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, 04 Feb 2012 18:48:39 -0000 On 2/4/2012 9:14 AM, Stefan Hakansson LK wrote: > If I understand things correctly, each file would be represented by a > blob object. So with the API Justin has proposed, with the addition of > the send(blob) (or with the API I proposed as well for that matter), the > app would just have to send each of those blobs. If the developer sends > them over one single channel, or opens several parallel is up to > her/him, but either way there would be no need to open/close, or to in > any way handle file start/stop - each file would be represented by a > discrete object, and the app just sends them. Are we assuming that the data channel will automatically split up and transfer the blob? And at the reception side, does it plop out as a blob at the other end? (Which implies buffering up the entire file before notifying the application it's coming, and removes the chance to stream it to disk or to an image element (or video element in some cases)). I was assuming a blob in this case was an opaque datagram to send to the other side, not (necessarily) a complete file object. > I assume that in this use case the html input element with type file > (and multiple attribute set) would be used so that the user can select > the files, Sure, though the interface between that selection and the calls to the dataChannel is an open question (and perhaps most reasonable to leave up to the application - provide good tools, not pre-packaged solutions). -- Randell Jesup randell-ietf@jesup.org From stefan.lk.hakansson@ericsson.com Sun Feb 5 02:27: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 B974221F8498 for ; Sun, 5 Feb 2012 02:27:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.145 X-Spam-Level: X-Spam-Status: No, score=-9.145 tagged_above=-999 required=5 tests=[AWL=1.454, 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 ibafcf+dVnvx for ; Sun, 5 Feb 2012 02:27:46 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id A200421F8491 for ; Sun, 5 Feb 2012 02:27:45 -0800 (PST) X-AuditID: c1b4fb3d-b7b26ae000000a35-a5-4f2e599f3188 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 9A.CE.02613.F995E2F4; Sun, 5 Feb 2012 11:27:44 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Sun, 5 Feb 2012 11:27:43 +0100 Message-ID: <4F2E599E.7020802@ericsson.com> Date: Sun, 5 Feb 2012 11:27:42 +0100 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F2B8F5A.3050709@ericsson.com> <4F2C1C63.4090602@alvestrand.no> <4F2C1E2E.9070200@ericsson.com> <4F2C568F.8040004@jesup.org> <4F2C6960.7050108@mozilla.com> <4F2D3D32.3010309@ericsson.com> <4F2D7D26.1030807@jesup.org> In-Reply-To: <4F2D7D26.1030807@jesup.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] SCTP mapping to data channels 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, 05 Feb 2012 10:27:46 -0000 On 02/04/2012 07:47 PM, Randell Jesup wrote: > On 2/4/2012 9:14 AM, Stefan Hakansson LK wrote: >> If I understand things correctly, each file would be represented by a >> blob object. So with the API Justin has proposed, with the addition of >> the send(blob) (or with the API I proposed as well for that matter), the >> app would just have to send each of those blobs. If the developer sends >> them over one single channel, or opens several parallel is up to >> her/him, but either way there would be no need to open/close, or to in >> any way handle file start/stop - each file would be represented by a >> discrete object, and the app just sends them. > > Are we assuming that the data channel will automatically split up and > transfer the blob? And at the reception side, does it plop out as a > blob at the other end? Yes, that is the (from me) expected behavior, in line with e.g. the WebSocket API. > (Which implies buffering up the entire file > before notifying the application it's coming, and removes the chance to > stream it to disk or to an image element (or video element in some cases)). > > I was assuming a blob in this case was an opaque datagram to send to the > other side, not (necessarily) a complete file object. It is not necessarily that; but in Tim's use case it was (thousands) of files. Blobs can be sliced and so on; refer to the File API spec. > >> I assume that in this use case the html input element with type file >> (and multiple attribute set) would be used so that the user can select >> the files, > > Sure, though the interface between that selection and the calls to the > dataChannel is an open question (and perhaps most reasonable to leave up > to the application - provide good tools, not pre-packaged solutions). I agree, I just wanted to ensure we're talking about the same thing. > From stefan.lk.hakansson@ericsson.com Sun Feb 5 08:03: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 07F8521F8547 for ; Sun, 5 Feb 2012 08:03:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.291 X-Spam-Level: X-Spam-Status: No, score=-9.291 tagged_above=-999 required=5 tests=[AWL=1.308, 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 L1lQCvxia5S6 for ; Sun, 5 Feb 2012 08:03:11 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED3B21F85A7 for ; Sun, 5 Feb 2012 08:03:10 -0800 (PST) X-AuditID: c1b4fb3d-b7b26ae000000a35-0c-4f2ea83da878 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id CB.0B.02613.D38AE2F4; Sun, 5 Feb 2012 17:03:10 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Sun, 5 Feb 2012 17:03:09 +0100 Message-ID: <4F2EA83B.2060108@ericsson.com> Date: Sun, 5 Feb 2012 17:03:07 +0100 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <607A2845-E8A6-4C66-BA1A-619E1B471B7C@vidyo.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] ICE with only TURN candidates: what should rel-addr/rel-port be? 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, 05 Feb 2012 16:03:12 -0000 Thinking out loud: If the server-reflexive/host candidates gives much more info (regarding location or anything else) than the IP-address any web server (using http) can get hold of now, isn't there a need for some user dialog to ack that? (Not that I know how it should be phrased.) Otherwise, any site you browse to could get to know this data (even if it is not a site offering communication of any kind) by setting up a PeerConnection object and ask it to gather candidates. Stefan On 02/04/2012 12:55 AM, Roman Shpount wrote: > > On Fri, Feb 3, 2012 at 6:39 PM, Martin Thomson > wrote: > > The point is that, at some level, the user has to trust the site they > are visiting before they grant the site access to PeerConnection. > > It _is_ possible to keep the server ignorant with a little trickery. > You use this new data bearer to exchange candidates and keep all but > relay candidates from the server, or always use your own TURN server > and always relay. The exchange of candidates would have to be > standardized though. Keep in mind that you also need to proxy your > HTTP traffic to the server as well. That's the trade-off, and maybe > that's an option that should remain on the table, but you can see > where "overkill" comes from. > > > I thought that TURN servers would be provisioned by the java script (web > site) and not the end user, or do we plan to provide an interface in web > browser settings that allows the overwrite for this? > > One more thing that an end user can do to ensure privacy, is to always > require to use a proxy. I am not sure if the decision have been made, if > proxy is required to be used, if specified by the end user. One option > is that if proxy is specified, the only candidate used would be a TURN > address obtained via a TCP or TLS connection established through proxy. > Unfortunately, this exactly the opposite of what you would want to do, > if you were trying to optimize the media for best performance, since in > this case you would try to connect to the TURN server directly even if > proxy is specified (and to use reflective or local IP if possible). > > Final consideration is that even if such options are provided in a web > browser, very few users would be educated enough to use them properly. > _____________ > Roman Shpount > > From Jim.Barnett@genesyslab.com Sun Feb 5 08:33: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 4A13D21F8547 for ; Sun, 5 Feb 2012 08:33:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O+Que+zpy2ub for ; Sun, 5 Feb 2012 08:33:13 -0800 (PST) Received: from relay-out1.dc.genesyslab.com (relay-out1.dc.genesyslab.com [198.49.180.220]) by ietfa.amsl.com (Postfix) with ESMTP id 8866C21F84EB for ; Sun, 5 Feb 2012 08:33:13 -0800 (PST) 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 q15GX9Db018517; Sun, 5 Feb 2012 08:33:09 -0800 (PST) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 5 Feb 2012 08:33:08 -0800 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: Sun, 5 Feb 2012 08:32:50 -0800 Message-ID: In-Reply-To: <4F2EA83B.2060108@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] ICE with only TURN candidates: what should rel-addr/rel-port be? Thread-Index: AczkH6x6wVG/Q2XIST+HZ2C8A7174gAA6Riw References: <607A2845-E8A6-4C66-BA1A-619E1B471B7C@vidyo.com> <4F2EA83B.2060108@ericsson.com> From: "Jim Barnett" To: "Stefan Hakansson LK" , X-OriginalArrivalTime: 05 Feb 2012 16:33:08.0998 (UTC) FILETIME=[D8404260:01CCE423] Subject: Re: [rtcweb] ICE with only TURN candidates: what should rel-addr/rel-port be? 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, 05 Feb 2012 16:33:14 -0000 If we delay ICE until the call is accepted, almost all these problems go away - though at the cost of greater set-up time. What if the default were that the caller starts gathering ICE candidates immediately, but the callee does not until the call is accepted? (In the case that Stefan is worried about, could a site start a start a call on the user's behalf without his consent?) - Jim -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Stefan Hakansson LK Sent: Sunday, February 05, 2012 11:03 AM To: rtcweb@ietf.org Subject: Re: [rtcweb] ICE with only TURN candidates: what should rel-addr/rel-port be? Thinking out loud: If the server-reflexive/host candidates gives much more info (regarding location or anything else) than the IP-address any web server (using http) can get hold of now, isn't there a need for some user dialog to ack that? (Not that I know how it should be phrased.) Otherwise, any site you browse to could get to know this data (even if it is not a site offering communication of any kind) by setting up a PeerConnection object and ask it to gather candidates. Stefan On 02/04/2012 12:55 AM, Roman Shpount wrote: > > On Fri, Feb 3, 2012 at 6:39 PM, Martin Thomson=20 > > wrote: > > The point is that, at some level, the user has to trust the site they > are visiting before they grant the site access to PeerConnection. > > It _is_ possible to keep the server ignorant with a little trickery. > You use this new data bearer to exchange candidates and keep all but > relay candidates from the server, or always use your own TURN server > and always relay. The exchange of candidates would have to be > standardized though. Keep in mind that you also need to proxy your > HTTP traffic to the server as well. That's the trade-off, and maybe > that's an option that should remain on the table, but you can see > where "overkill" comes from. > > > I thought that TURN servers would be provisioned by the java script=20 > (web > site) and not the end user, or do we plan to provide an interface in=20 > web browser settings that allows the overwrite for this? > > One more thing that an end user can do to ensure privacy, is to always > require to use a proxy. I am not sure if the decision have been made,=20 > if proxy is required to be used, if specified by the end user. One=20 > option is that if proxy is specified, the only candidate used would be > a TURN address obtained via a TCP or TLS connection established through proxy. > Unfortunately, this exactly the opposite of what you would want to do, > if you were trying to optimize the media for best performance, since=20 > in this case you would try to connect to the TURN server directly even > if proxy is specified (and to use reflective or local IP if possible). > > Final consideration is that even if such options are provided in a web > browser, very few users would be educated enough to use them properly. > _____________ > Roman Shpount > > _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From matthew.kaufman@skype.net Sun Feb 5 08:34: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 A27F221F8596 for ; Sun, 5 Feb 2012 08:34:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JtFtKBjk2--o for ; Sun, 5 Feb 2012 08:34:45 -0800 (PST) Received: from AM1EHSOBE003.bigfish.com (am1ehsobe002.messaging.microsoft.com [213.199.154.205]) by ietfa.amsl.com (Postfix) with ESMTP id 82C2A21F8593 for ; Sun, 5 Feb 2012 08:34:44 -0800 (PST) Received: from mail65-am1-R.bigfish.com (10.3.201.250) by AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id 14.1.225.23; Sun, 5 Feb 2012 16:34:43 +0000 Received: from mail65-am1 (localhost [127.0.0.1]) by mail65-am1-R.bigfish.com (Postfix) with ESMTP id 6903B2C0275; Sun, 5 Feb 2012 16:34:43 +0000 (UTC) X-SpamScore: 0 X-BigFish: VS0(zzzz1202hzzz2fh87h2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail65-am1: domain of skype.net designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=matthew.kaufman@skype.net; helo=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; X-FB-DOMAIN-IP-MATCH: fail Received: from mail65-am1 (localhost.localdomain [127.0.0.1]) by mail65-am1 (MessageSwitch) id 1328459681465869_7980; Sun, 5 Feb 2012 16:34:41 +0000 (UTC) Received: from AM1EHSMHS017.bigfish.com (unknown [10.3.201.233]) by mail65-am1.bigfish.com (Postfix) with ESMTP id 6D6A6240045; Sun, 5 Feb 2012 16:34:41 +0000 (UTC) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS017.bigfish.com (10.3.207.155) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 5 Feb 2012 16:34:41 +0000 Received: from TK5EX14MBXC274.redmond.corp.microsoft.com ([169.254.3.210]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0247.005; Sun, 5 Feb 2012 08:34:39 -0800 From: Matthew Kaufman To: Jim Barnett , Stefan Hakansson LK , "rtcweb@ietf.org" Thread-Topic: [rtcweb] ICE with only TURN candidates: what should rel-addr/rel-port be? Thread-Index: AQHM5CPoXxvxhTxqikmwOKzZ/RfAx5Yuf6Bw Date: Sun, 5 Feb 2012 16:34:38 +0000 Message-ID: References: <607A2845-E8A6-4C66-BA1A-619E1B471B7C@vidyo.com> <4F2EA83B.2060108@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.32] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [rtcweb] ICE with only TURN candidates: what should rel-addr/rel-port be? 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, 05 Feb 2012 16:34:45 -0000 Jim Barnett: > If we delay ICE until the call is accepted, almost all these problems go = away - though at the cost of greater set-up time. What is "the call is accepted" for a data-only connection? Matthew Kaufman From stefan.lk.hakansson@ericsson.com Sun Feb 5 08:52: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 31EF221F8498 for ; Sun, 5 Feb 2012 08:52:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.41 X-Spam-Level: X-Spam-Status: No, score=-9.41 tagged_above=-999 required=5 tests=[AWL=1.189, 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 7IzOImTSVDvB for ; Sun, 5 Feb 2012 08:52:32 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 747C821F8491 for ; Sun, 5 Feb 2012 08:52:32 -0800 (PST) X-AuditID: c1b4fb3d-b7b26ae000000a35-af-4f2eb3cfe471 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 42.2D.02613.FC3BE2F4; Sun, 5 Feb 2012 17:52:31 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Sun, 5 Feb 2012 17:52:30 +0100 Message-ID: <4F2EB3CC.9020602@ericsson.com> Date: Sun, 5 Feb 2012 17:52:28 +0100 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: Matthew Kaufman References: <607A2845-E8A6-4C66-BA1A-619E1B471B7C@vidyo.com> <4F2EA83B.2060108@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] ICE with only TURN candidates: what should rel-addr/rel-port be? 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, 05 Feb 2012 16:52:33 -0000 On 02/05/2012 05:34 PM, Matthew Kaufman wrote: > Jim Barnett: >> If we delay ICE until the call is accepted, almost all these problems go away - though at the cost of greater set-up time. > > What is "the call is accepted" for a data-only connection? Exactly, and my case was that there was even no intention to set up a data connection - the (evil) site creates a PeerConnection object and asks it to gather candidates with the sole purpose of getting access to IP-addresses. Stefan > > Matthew Kaufman > > From Jim.Barnett@genesyslab.com Sun Feb 5 09:40: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 8CD2421F8584 for ; Sun, 5 Feb 2012 09:40:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNAsXhMEUJTm for ; Sun, 5 Feb 2012 09:40:32 -0800 (PST) Received: from relay-out1.dc.genesyslab.com (relay-out1.dc.genesyslab.com [198.49.180.220]) by ietfa.amsl.com (Postfix) with ESMTP id 1706B21F856C for ; Sun, 5 Feb 2012 09:40:31 -0800 (PST) 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 q15HeR9E025097; Sun, 5 Feb 2012 09:40:27 -0800 (PST) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 5 Feb 2012 09:40:27 -0800 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: Sun, 5 Feb 2012 09:40:09 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] ICE with only TURN candidates: what shouldrel-addr/rel-port be? Thread-Index: AQHM5CPoXxvxhTxqikmwOKzZ/RfAx5Yuf6BwgAARSeA= References: <607A2845-E8A6-4C66-BA1A-619E1B471B7C@vidyo.com><4F2EA83B.2060108@ericsson.com> From: "Jim Barnett" To: "Matthew Kaufman" , "Stefan Hakansson LK" , X-OriginalArrivalTime: 05 Feb 2012 17:40:27.0144 (UTC) FILETIME=[3F2C7080:01CCE42D] Subject: Re: [rtcweb] ICE with only TURN candidates: what shouldrel-addr/rel-port be? 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, 05 Feb 2012 17:40:32 -0000 Good question, but I think that if we want the defaults to offer privacy/security, the "caller" and the "callee" would still have to give explicit permission to create the data-only connection before ICE could begin (i.e. once the caller gave consent to create the connection, ICE could begin on their side, and once the callee gave consent to accept the connection, ICE could begin on their side.) For the .01% of the population that changes the defaults, there could be an 'allow quick connection' option (presumably restricted to specific addresses), just as there could be an 'always accept connection' override (also restricted by address.) - Jim -----Original Message----- From: Matthew Kaufman [mailto:matthew.kaufman@skype.net]=20 Sent: Sunday, February 05, 2012 11:35 AM To: Jim Barnett; Stefan Hakansson LK; rtcweb@ietf.org Subject: RE: [rtcweb] ICE with only TURN candidates: what shouldrel-addr/rel-port be? Jim Barnett: > If we delay ICE until the call is accepted, almost all these problems go away - though at the cost of greater set-up time. What is "the call is accepted" for a data-only connection? Matthew Kaufman From christer.holmberg@ericsson.com Sun Feb 5 20:06: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 5D15621F852B; Sun, 5 Feb 2012 20:06:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.281 X-Spam-Level: X-Spam-Status: No, score=-7.281 tagged_above=-999 required=5 tests=[AWL=-0.545, BAYES_00=-2.599, FRT_SOMA=1.664, FRT_SOMA2=2.199, 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 7UnUvGECKxiM; Sun, 5 Feb 2012 20:06:19 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 4618321F8547; Sun, 5 Feb 2012 20:06:19 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-fb-4f2f51b7d960 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 90.7D.27041.7B15F2F4; Mon, 6 Feb 2012 05:06:15 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Mon, 6 Feb 2012 05:06:15 +0100 From: Christer Holmberg To: Ted Hardie , Matthew Kaufman Date: Mon, 6 Feb 2012 05:06:14 +0100 Thread-Topic: [rtcweb] ICE with only TURN candidates: what should rel-addr/rel-port be? Thread-Index: AczixrkVOwmmReELS7KZWQyrTe5CnwBvIo9M Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3D31B9D7@ESESSCMS0356.eemea.ericsson.se> References: <607A2845-E8A6-4C66-BA1A-619E1B471B7C@vidyo.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Jonathan Lennox , "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [rtcweb] ICE with only TURN candidates: what should rel-addr/rel-port be? 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, 06 Feb 2012 04:06:20 -0000 Hi, For clarification, what do we exactly mean by "answering the call"? Do we mean: a) that the called party has accepted the call, and actually "lifted the ho= ok", or=20 b) that the called party has been made aware (alterted) about the incoming = call, but has not yet accepted it, and may or may not accept it? We also have to remember that ICE is not the only way to reveal IP addresse= s. The signalling protocol (depending on which one we use) can also reveal = IP addresses/ports in other protocol elements.=20 And, taking SIP as an example: if we don't allow revealing of IP addresses = before the call has been answered, it would prevent a SIP app from sending = provisional responses with Contact header fields. Regards, Christer ________________________________________ From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] On Behalf Of Ted Ha= rdie [ted.ietf@gmail.com] Sent: Saturday, February 04, 2012 12:53 AM To: Matthew Kaufman Cc: Jonathan Lennox; mmusic@ietf.org; rtcweb@ietf.org Subject: Re: [rtcweb] ICE with only TURN candidates: what should rel-addr/r= el-port be? On Fri, Feb 3, 2012 at 11:21 AM, Matthew Kaufman wrote: > > Requiring the browser to *never* be able to provide the STUN or local add= ress before answering is overkill (and providers who want faster connection= s will circumvent by >building a brief null call and figuring it out that w= ay). > Obviously we can disagree about "overkill" when it comes to the balance between latency and privacy, but before we go there, I want to make sure I understand what you mean by a null call. If I understand the optimization, you're proposing having the downloaded javascript instantiate a session to the server ("call home on download"), so that the server can collect the addresses it uses and then hand them out to any other user who wishes to make a call to the user. If that is the proposal, I have to say that I think it runs directly counter to the privacy imperative we just identified. Let's imagine our vampire friends at deadjournal decide to do this. If I want to find out where the holder of sparklyvamp@deadjournal.com is, er, living, I can set up a script that attempts to autocall them every N minutes and then lookup. Whenever they sign in, deadjournal will collect their IPs and send them over to me for use in my call. sparklyvamp may very well know I am staker, and decide not to answer. In the mean time, however, I'm on my way with holy water, garlic, and a sharpened stick. In order to avoid this fate, sparklyvamp must know whether or not any particular service they use which *might* embed audio and video in some parts of the applications they provide or host will or will not use this. This includes the services deadjournal hosts for Zomga, the well-known undead games maker. Have I misunderstood your optimization? Ted _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb= From oscar.ohlsson@ericsson.com Mon Feb 6 02:19: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 D4CF621F85B4 for ; Mon, 6 Feb 2012 02:19:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.799 X-Spam-Level: X-Spam-Status: No, score=-8.799 tagged_above=-999 required=5 tests=[AWL=1.200, BAYES_00=-2.599, J_CHICKENPOX_55=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 FAsWfhd+ikaO for ; Mon, 6 Feb 2012 02:19:25 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 5E9B421F8585 for ; Mon, 6 Feb 2012 02:19:24 -0800 (PST) X-AuditID: c1b4fb3d-b7b26ae000000a35-42-4f2fa92a7f9e Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 41.44.02613.A29AF2F4; Mon, 6 Feb 2012 11:19:22 +0100 (CET) Received: from ESESSCMS0360.eemea.ericsson.se ([169.254.1.48]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Mon, 6 Feb 2012 11:19:22 +0100 From: Oscar Ohlsson To: Magnus Westerlund , "rtcweb@ietf.org" Date: Mon, 6 Feb 2012 11:19:21 +0100 Thread-Topic: [rtcweb] DoS attack despite ICE/STUN consent verification Thread-Index: AczhMTw+YyH8JMKBQbKJ96EzIADTDADg0gng Message-ID: References: <4F29BD31.9040700@ericsson.com> In-Reply-To: <4F29BD31.9040700@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] DoS attack despite ICE/STUN consent verification 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, 06 Feb 2012 10:19:25 -0000 =20 > -----Original Message----- > From: rtcweb-bounces@ietf.org=20 > [mailto:rtcweb-bounces@ietf.org] On Behalf Of Magnus Westerlund > Sent: den 1 februari 2012 23:31 > To: rtcweb@ietf.org > Subject: [rtcweb] DoS attack despite ICE/STUN consent verification >=20 > Hi, >=20 > As I brought up in yesterdays meeting I think there exist an=20 > attack that should be considered. I don't think it is super=20 > strong, but not without issues. >=20 > Setting: >=20 > Webserver is evil and have a target Alice. Alice can be a=20 > legacy device, like a SIP/SDP video phone. It knows the=20 > target is doing ICE and have Alice's ufrag and password and=20 > candidates. The server would like to hammer this target by=20 > utilizing its set of connected WebRTC clients (bob, charlie=20 > etc.). Thus it would like to ensure that it gets the browser=20 > to start sending RTP media when creating a PeerConnection in=20 > the clients. >=20 > So the server gets the client to open PeerConnections towards=20 > the ICE parameters from the target (Alice). >=20 > In default ICE behavior there is an optimization to allow the Offerer > (Alice) to respond to STUN binding requests from Bob without=20 > having received an SDP answer from Bob. The STUN binding=20 > request must only have the Alice's ufrag and its password.=20 > This enables that Webrtc clients can get passed the data=20 > consent step with ICE capable end-point for which the ICE=20 > parameters can be retrieved. >=20 > So from Alice perspective this attack will look like its=20 > offer got forked to many peers based on the many different=20 > peers that send STUN messages. The webserver could even=20 > provide SIP/SDP answers to alice with the webclients. But=20 > that is not necessary but is one variation of this. Correct me if I'm wrong, but I believe the webserver must provide the SIP/S= DP answers. As far as I can tell there are always two connectivity checks, = one for each direction (Section 2.2 RFC 5245): L R - - STUN request -> \ L's <- STUN response / check <- STUN request \ R's STUN response -> / check Alice would automatically respond to the remote side's check. However, in o= rder to genereate her own check (R's check in the diagram) she would need t= o have received the remote side's password. According to Section 7.1.2.3. i= n RFC 5245: "A connectivity check from R to L utilizes the username LFRAG:RFRAG and a p= assword of LPASS." If this interpretation is correct then counter-measure A below would always= be a possibility. >=20 > So what are the mitigations. >=20 > A) If Alice receives SIP/SDP answers it can start triaging=20 > the many response and decide which it shouldn't answer to=20 > based on SIP/SDP information and the ignore in STUN layer=20 > based on the far side ufrag. >=20 > B) Alice can stop answering to the STUN binding requests.=20 > However, that opens her up to denial of service attack if the=20 > method for Evil to acquire here ICE parameters is to snoop a=20 > legitimate intentional call. > By not responding to a STUN binding response from different=20 > peers after having seen N peers allows evil to block the=20 > intended call. This mitigation may not work in cases where we=20 > can't enforce the browser to generate the ufrag on the WebRTC=20 > client side. Like what I objected to allow the ICE parameters=20 > to be set by SetLocalDescription. >=20 > C) Continued Data consent: This can work but each WebRTC=20 > client will send for 30 s at least until it stops sending.=20 > The reason it may work is that default SIP/SDP ICE capable=20 > end-points may not support STUN binding responses during the=20 > call as that is not specified. It may however work if the=20 > implementation doesn't intentionally blocks binding responses=20 > after ICE processing has ceased. If Alice intentionally wants=20 > to block the media flows it can ensure that it doesn't send. >=20 > D) RTP media adaptation / Congestion control. Alice can=20 > either refuse to send RTCP feedback or intentional feedback=20 > to reduced the transmission rate to a minimal. However, there=20 > is some lower limit where just basic probing traffic, low=20 > rate audio is sent over the media channel. However, it is not=20 > certain that this stops media transmission completely. >=20 > E) If DTLS-SRTP is used then that handshake must complete. So=20 > if Alice doesn't support DTLS-SRTP it will not answer, thus=20 > preventing the WebRTC client to start sending media. If alice=20 > supports DTLS-SRTP then alice has some potential to refuse to=20 > respond based on the WebRTC clients used certificate.=20 > However, if it doesn't check that against an answer in the=20 > middle of the DTLS handshake, the WebRTC client could succeed=20 > in the DTLS-SRTP keying and start sending media, while Alice=20 > realizes that this is not the client it wants to talk to. >=20 > So from my perspective, this is an attack that provides some=20 > potential for an overload / denial of service attack on Alice=20 > with the benefit that the one generating the traffic to Alice=20 > is the WebRTC clients. It will require some work from the=20 > webserver to keep the clients connect to some ICE candidate=20 > address which they expose or can get to expose. >=20 > Comments on the strength of the attack and the=20 > weakness/strengths of the mitigations >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > = From salvatore.loreto@ericsson.com Mon Feb 6 03:24: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 B097E21F8636 for ; Mon, 6 Feb 2012 03:24:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.892 X-Spam-Level: X-Spam-Status: No, score=-108.892 tagged_above=-999 required=5 tests=[AWL=1.707, 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 v8t31dwtrhxy for ; Mon, 6 Feb 2012 03:24:10 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id DDAAD21F862B for ; Mon, 6 Feb 2012 03:24:09 -0800 (PST) X-AuditID: c1b4fb3d-b7b26ae000000a35-a5-4f2fb8587ba8 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id E2.E1.02613.858BF2F4; Mon, 6 Feb 2012 12:24:09 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Mon, 6 Feb 2012 12:24:08 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 548A72189 for ; Mon, 6 Feb 2012 13:24:08 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 3907051E4E for ; Mon, 6 Feb 2012 13:24:08 +0200 (EET) Received: from n106.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id E8CF84F690 for ; Mon, 6 Feb 2012 13:24:07 +0200 (EET) Message-ID: <4F2FB857.3070108@ericsson.com> Date: Mon, 6 Feb 2012 13:24:07 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F29D2A6.4090802@ericsson.com> In-Reply-To: <4F29D2A6.4090802@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] Confirming consensus from Interim: Data protocol and security mechanism 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, 06 Feb 2012 11:24:10 -0000 I agree on both on using SCTP as transport protocol for data and SCTP/DTLS/UDP br Salvatore On 2/2/12 2:02 AM, Magnus Westerlund wrote: > WG, > > This is a 2 week call for confirming the consensus of the interim > meeting regarding data transport. The WG members not present at the > interim are requested to indicate support or objections on the consensus > from the interim. This email contains two calls related to the data > transport. Please provide any input no later than the 15th of February. > > The jabber logs are pretty well capturing the discussion. Please see > from 00:18:36 in > http://www.ietf.org/jabber/logs/rtcweb/2012-02-01.html > > The first consensus call made was which transport protocol that should > be used. Based on the discussion it was clear that SCTP was favored and > that was confirmed by the consensus call. Where 19 participants > preferred SCTP as the transport protocol for the data channel and 3 > desired something else. The WG declared clear consensus for using SCTP > as the transport protocol for data. Does the WG participants not present > agrees or objects? > > The seconds consensus call was on the order of SCTP and DTLS on top of > UDP. The two alternatives are: SCTP/DTLS/UDP or DTLS/SCTP/UDP. This was > a unanimous consensus, where 18 preferred SCTP/DTLS/UDP, and no for the > other order. Does the WG participants not present agrees or objects? > > 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 > ---------------------------------------------------------------------- > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From magnus.westerlund@ericsson.com Mon Feb 6 06:28: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 C480621F8606 for ; Mon, 6 Feb 2012 06:28:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.751 X-Spam-Level: X-Spam-Status: No, score=-109.751 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TcI0eoCjwTpS for ; Mon, 6 Feb 2012 06:28:05 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id E1F3F21F85CF for ; Mon, 6 Feb 2012 06:28:04 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-28-4f2fe3738fa2 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 01.C8.27041.373EF2F4; Mon, 6 Feb 2012 15:28:03 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Mon, 6 Feb 2012 15:28:03 +0100 Message-ID: <4F2FE368.6040207@ericsson.com> Date: Mon, 6 Feb 2012 15:27:52 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Oscar Ohlsson References: <4F29BD31.9040700@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DoS attack despite ICE/STUN consent verification 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, 06 Feb 2012 14:28:05 -0000 On 2012-02-06 11:19, Oscar Ohlsson wrote: > > >> -----Original Message----- >> From: rtcweb-bounces@ietf.org >> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Magnus Westerlund >> Sent: den 1 februari 2012 23:31 >> To: rtcweb@ietf.org >> Subject: [rtcweb] DoS attack despite ICE/STUN consent verification >> >> Hi, >> >> As I brought up in yesterdays meeting I think there exist an >> attack that should be considered. I don't think it is super >> strong, but not without issues. >> >> Setting: >> >> Webserver is evil and have a target Alice. Alice can be a >> legacy device, like a SIP/SDP video phone. It knows the >> target is doing ICE and have Alice's ufrag and password and >> candidates. The server would like to hammer this target by >> utilizing its set of connected WebRTC clients (bob, charlie >> etc.). Thus it would like to ensure that it gets the browser >> to start sending RTP media when creating a PeerConnection in >> the clients. >> >> So the server gets the client to open PeerConnections towards >> the ICE parameters from the target (Alice). >> >> In default ICE behavior there is an optimization to allow the Offerer >> (Alice) to respond to STUN binding requests from Bob without >> having received an SDP answer from Bob. The STUN binding >> request must only have the Alice's ufrag and its password. >> This enables that Webrtc clients can get passed the data >> consent step with ICE capable end-point for which the ICE >> parameters can be retrieved. >> >> So from Alice perspective this attack will look like its >> offer got forked to many peers based on the many different >> peers that send STUN messages. The webserver could even >> provide SIP/SDP answers to alice with the webclients. But >> that is not necessary but is one variation of this. > > > Correct me if I'm wrong, but I believe the webserver must provide the SIP/SDP answers. As far as I can tell there are always two connectivity checks, one for each direction (Section 2.2 RFC 5245): > L R > - - > STUN request -> \ L's > <- STUN response / check > > <- STUN request \ R's > STUN response -> / check > > Alice would automatically respond to the remote side's check. > However, in order to genereate her own check (R's check in the > diagram) she would need to have received the remote side's password. > According to Section 7.1.2.3. in RFC 5245: > > "A connectivity check from R to L utilizes the username LFRAG:RFRAG > and a password of LPASS." > > If this interpretation is correct then counter-measure A below would > always be a possibility. > Oscar, >From L's perspective, the process of nomination and validation can complete without R having succeeded. Thus L (WebRTC Browser) can start send media to R without R having successfully validated any return path from R to L. Thus, I don't see how A could be made to reliably work as a mitigation. In addition are there anyone who actually have this type of attack protection in their SIP stacks or SIP proxies? 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 martin.thomson@gmail.com Mon Feb 6 10:56: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 9176521F8711 for ; Mon, 6 Feb 2012 10:56:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.384 X-Spam-Level: X-Spam-Status: No, score=-4.384 tagged_above=-999 required=5 tests=[AWL=-0.785, 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 h8txBpj07w4I for ; Mon, 6 Feb 2012 10:56:54 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5101621F8707 for ; Mon, 6 Feb 2012 10:56:54 -0800 (PST) Received: by bkbzt4 with SMTP id zt4so5565755bkb.31 for ; Mon, 06 Feb 2012 10:56:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=45fSJ2u3dWBgaXmo5r89mo+JrXy08OdfkHQd5RjuErA=; b=GNfQDFrI4F7CLCGV8hT7aTRKk8I/qIQuoI0S/2jpFytBHJiBcS+aXGql/NWlYKNEY+ +3By2tINuMNYjHWnewXAa4Oag1y7btT+fsZ/xrdKoOYqMr917oLIFXhh+tTjVfC/6Sn/ ddkkWzlOBBH3Oi4gjEiZflD6wGYLEtqjUJi8I= MIME-Version: 1.0 Received: by 10.204.152.216 with SMTP id h24mr9181577bkw.15.1328554613308; Mon, 06 Feb 2012 10:56:53 -0800 (PST) Received: by 10.204.241.81 with HTTP; Mon, 6 Feb 2012 10:56:53 -0800 (PST) In-Reply-To: References: <607A2845-E8A6-4C66-BA1A-619E1B471B7C@vidyo.com> Date: Mon, 6 Feb 2012 10:56:53 -0800 Message-ID: From: Martin Thomson To: Roman Shpount Content-Type: text/plain; charset=UTF-8 Cc: Jonathan Lennox , "rtcweb@ietf.org" Subject: Re: [rtcweb] ICE with only TURN candidates: what should rel-addr/rel-port be? 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, 06 Feb 2012 18:56:57 -0000 On 3 February 2012 15:55, Roman Shpount wrote: > I thought that TURN servers would be provisioned by the java script (web > site) and not the end user, or do we plan to provide an interface in web > browser settings that allows the overwrite for this? I'm not aware of whether anyone is planning anything at all in particular. Though I observe that since the browser is the one performing the ICE parts, including contacting the TURN server, there is nothing stopping someone from building a browser that has an option for locking down the TURN negotiation to a single server. Of course, there is nothing stopping the Javascript from inserting and removing candidates from the list. And nor should there be, though that is just my opinion. The browser only has control over where it sends packets. From sohel_khan@cable.comcast.com Mon Feb 6 11:42: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 8E61B21F869F for ; Mon, 6 Feb 2012 11:42:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.462 X-Spam-Level: X-Spam-Status: No, score=-108.462 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 5Xe3Bb7LXkfD for ; Mon, 6 Feb 2012 11:42:45 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0B121F869E for ; Mon, 6 Feb 2012 11:42:44 -0800 (PST) Received: from ([24.40.55.42]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.150832334; Mon, 06 Feb 2012 14:42:39 -0500 Received: from PACDCEXMB02.cable.comcast.com ([fe80::9803:aba4:1ac8:474e]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0355.002; Mon, 6 Feb 2012 14:42:39 -0500 From: "Khan, Sohel" To: "rtcweb@ietf.org" Thread-Topic: Incoming Call for RTCWeb using Websocket extention or HTTP custom-make signaling protocol Thread-Index: AczlAyHWUiYAwy9sTYKPiClYMlxAyg== Date: Mon, 6 Feb 2012 19:42:38 +0000 Deferred-Delivery: Mon, 6 Feb 2012 19:42:00 +0000 Message-ID: <837E772D16C77141BFA5FEC3F30487FF525B89EC@PACDCEXMB02.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.40.56.171] Content-Type: multipart/alternative; boundary="_000_837E772D16C77141BFA5FEC3F30487FF525B89ECPACDCEXMB02cabl_" MIME-Version: 1.0 Subject: [rtcweb] Incoming Call for RTCWeb using Websocket extention or HTTP custom-make signaling protocol 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, 06 Feb 2012 19:42:45 -0000 --_000_837E772D16C77141BFA5FEC3F30487FF525B89ECPACDCEXMB02cabl_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable My question pertains to RTCWeb Incoming call. Please assume for this discussion, RTCWeb system uses Websocket extention= or HTTP custom-make signaling protocol. Also, please assume that a NAT or multiple NAT exist between the RTCWeb ser= ver and the RTC Web client (Receiver). Here, the sender of the call is Alice and receiver of the call is Bob. We would like to discuss the signaling protocol between the RTC Web Server = to Bob |RTC Web Server|----->|NAT|--->RTC Web-Client (receiver). Sorry, I could not attend the interim meeting. I reviewed the interim meeti= ng presentations and could not understand Incoming RTC session to receiver = through a NAT, when the RTCWeb client system is built using Websocket exten= tion or HTTP custom-make signaling protocol. Is there any proposal in this scenario? Sincerely appreciate your help. Thank you. Sohel Khan --_000_837E772D16C77141BFA5FEC3F30487FF525B89ECPACDCEXMB02cabl_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

My question pertains to RTCWeb Incoming call.

Please assume for this discussion,  RTCWeb = ; system uses Websocket extention or HTTP custom-make signaling protocol.

Also, please assume that a NAT or multiple NAT exist= between the RTCWeb server and the RTC  Web client (Receiver).

Here, the sender of the call is Alice and receiver o= f the call is Bob.

We would like to discuss the signaling protocol betw= een the RTC Web Server to Bob

 

|RTC Web Server|---=E0|NAT|-=E0RTC We= b-Client (receiver).

 

Sorry, I could not attend the interim meeting. I rev= iewed the interim meeting presentations and could not understand Incoming R= TC session to receiver through a NAT, when the RTCWeb client system is buil= t using Websocket extention or HTTP custom-make signaling protocol.

 

Is there any proposal in this scenario?

Sincerely appreciate your help.

 

Thank you.

 

Sohel Khan

--_000_837E772D16C77141BFA5FEC3F30487FF525B89ECPACDCEXMB02cabl_-- From sohel_khan@cable.comcast.com Mon Feb 6 12:59: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 55D8021F86FD for ; Mon, 6 Feb 2012 12:59:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.846 X-Spam-Level: X-Spam-Status: No, score=-104.846 tagged_above=-999 required=5 tests=[AWL=-3.616, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HB6RfW9awkE7 for ; Mon, 6 Feb 2012 12:59:32 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id ED22D21F86C7 for ; Mon, 6 Feb 2012 12:59:31 -0800 (PST) Received: from ([24.40.56.116]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.5287809; Mon, 06 Feb 2012 13:49:56 -0700 Received: from PACDCEXMB02.cable.comcast.com ([fe80::9803:aba4:1ac8:474e]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%15]) with mapi id 14.01.0355.002; Mon, 6 Feb 2012 15:59:29 -0500 From: "Khan, Sohel" To: "rtcweb@ietf.org" Thread-Topic: Incoming Call for RTCWeb using SIP Thread-Index: AczlDObhJf3Knz4gT12APVHQzYRQdA== Date: Mon, 6 Feb 2012 20:59:28 +0000 Deferred-Delivery: Mon, 6 Feb 2012 20:59:00 +0000 Message-ID: <837E772D16C77141BFA5FEC3F30487FF525B8A98@PACDCEXMB02.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.40.56.171] Content-Type: multipart/alternative; boundary="_000_837E772D16C77141BFA5FEC3F30487FF525B8A98PACDCEXMB02cabl_" MIME-Version: 1.0 Subject: [rtcweb] Incoming Call for RTCWeb using SIP 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, 06 Feb 2012 20:59:33 -0000 --_000_837E772D16C77141BFA5FEC3F30487FF525B8A98PACDCEXMB02cabl_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable My question pertains to RTCWeb Incoming call. Please assume for this discussion, RTCWeb uses SIP. Also, please assume that a NAT or multiple NAT exist between the SIP-Web se= rver and the RTC Web client (Receiver). Here, the sender of the call is Alice and receiver of the call is Bob. We would like to discuss the signaling protocol between the RTC Web Server = to Bob |RTC SIP-Web Server|----->|NAT|--->RTC Web-Client (receiver). RFC 5128 Section 3.2 Connection reversal is an interesting method that we c= an consider for an incoming call. http://datatracker.ietf.org/doc/rfc5128/?include_text=3D1 Client A is behind a NAT, but client B has a publicly addressable IP address. Rendezvous Server S has a publicly addressable IP address and is used for the purposes of registration and discovery. Hosts behind a NAT register their endpoints with the server. Peer hosts discover endpoints of hosts behind a NAT using the server ... Now suppose client B wishes to establish a direct communication session wit= h client A. ... After attempting and failing to establish a direct connection to A, client B can use server S to relay a request to client A to initiate a "reversed" connection to client B. Client A, upon receiving this relayed request through S, opens a TCP connection to client B at B's public IP address and port number. NAT A allows the connection to proceed because it is originating inside the firewall, and client B can receive the connection because it is not behind a NAT device. ... In RTCweb architecture, for incoming calls, are we thinking RFC5128 section= 3.2 method or any other similar innovative method? Appreciate to hear your opinion. Sohel Khan, Comcast --_000_837E772D16C77141BFA5FEC3F30487FF525B8A98PACDCEXMB02cabl_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

My question pertains to RTCWeb Incoming call.

Please assume for this discussion,  RTCWeb = ; uses SIP.

Also, please assume that a NAT or multiple NAT exist= between the SIP-Web server and the RTC Web client (Receiver).

Here, the sender of the call is Alice and receiver o= f the call is Bob.

We would like to discuss the signaling protocol betw= een the RTC Web Server to Bob

 

|RTC SIP-Web Server|---=E0|NAT|-=E0RT= C Web-Client (receiver).

 

RFC 5128 Section 3.2 Connection reversal is an inter= esting method that we can consider for an incoming call.

http://datatracker.ietf.org/doc/rfc5128/?include_text=3D1=

Client A is behind a NAT, but= client B has a publicly addressable

IP address.  Rendezvous = Server S has a publicly addressable IP

address and is used for the p= urposes of registration and discovery.

Hosts behind a NAT register t= heir endpoints with the server.  Peer

hosts discover endpoints of hosts behind a NAT using the s= erver …

Now suppose client B wishes t= o establish a direct communication session with client A. …

After attempting and failing = to establish a direct connection to A,

client B can use server S to = relay a request to client A to initiate

a "reversed" connec= tion to client B.  Client A, upon receiving this

relayed request through S, op= ens a TCP connection to client B at B's

public IP address and port nu= mber.  NAT A allows the connection to

proceed because it is origina= ting inside the firewall, and client B

can receive the connection be= cause it is not behind a NAT device.

…

In RTCweb architecture, for i= ncoming calls, are we thinking RFC5128 section 3.2 method or any other simi= lar innovative method?

 

Appreciate to hear your opini= on.

 

Sohel Khan, Comcast

 

 

 

--_000_837E772D16C77141BFA5FEC3F30487FF525B8A98PACDCEXMB02cabl_-- From randell-ietf@jesup.org Tue Feb 7 02: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 48C2D21F87B4 for ; Tue, 7 Feb 2012 02:01:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.397 X-Spam-Level: X-Spam-Status: No, score=-2.397 tagged_above=-999 required=5 tests=[AWL=0.202, 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 b43EJS7uS8do for ; Tue, 7 Feb 2012 02:01:30 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id A2DA221F87B2 for ; Tue, 7 Feb 2012 02:01:30 -0800 (PST) Received: from pool-173-49-135-74.phlapa.fios.verizon.net ([173.49.135.74] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Ruhrd-0004oS-QR for rtcweb@ietf.org; Tue, 07 Feb 2012 04:01:29 -0600 Message-ID: <4F30F614.2000403@jesup.org> Date: Tue, 07 Feb 2012 04:59:48 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <837E772D16C77141BFA5FEC3F30487FF525B8A98@PACDCEXMB02.cable.comcast.com> In-Reply-To: <837E772D16C77141BFA5FEC3F30487FF525B8A98@PACDCEXMB02.cable.comcast.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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] Incoming Call for RTCWeb using SIP 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, 07 Feb 2012 10:01:31 -0000 On 2/6/2012 3:59 PM, Khan, Sohel wrote: > |RTC SIP-Web Server|---à|NAT|-àRTC Web-Client (receiver). > > RFC 5128 Section 3.2 Connection reversal is an interesting method that > we can consider for an incoming call. > > http://datatracker.ietf.org/doc/rfc5128/?include_text=1 Please read up on ICE (another IETF RFC), which is what we're specing WebRTC to use. -- Randell Jesup randell-ietf@jesup.org From fluffy@fluffy.im Tue Feb 7 05:22: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 CE5A821F8605; Tue, 7 Feb 2012 05:22:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.485 X-Spam-Level: X-Spam-Status: No, score=-3.485 tagged_above=-999 required=5 tests=[AWL=0.114, 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 zBZfAov4-FGi; Tue, 7 Feb 2012 05:22:56 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 78B7421F8562; Tue, 7 Feb 2012 05:22:55 -0800 (PST) Received: by iagf6 with SMTP id f6so12135624iag.31 for ; Tue, 07 Feb 2012 05:22:55 -0800 (PST) Received: by 10.43.53.1 with SMTP id vo1mr26301255icb.2.1328620975131; Tue, 07 Feb 2012 05:22:55 -0800 (PST) Received: from [192.168.4.100] (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id ub10sm21057577igb.7.2012.02.07.05.22.53 (version=SSLv3 cipher=OTHER); Tue, 07 Feb 2012 05:22:54 -0800 (PST) Sender: Cullen Jennings Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Tue, 7 Feb 2012 06:22:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <607A2845-E8A6-4C66-BA1A-619E1B471B7C@vidyo.com> To: Roman Shpount X-Mailer: Apple Mail (2.1084) Cc: Jonathan Lennox , "mmusic@ietf.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] [MMUSIC] ICE with only TURN candidates: what should rel-addr/rel-port be? 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, 07 Feb 2012 13:22:57 -0000 On Feb 3, 2012, at 4:55 PM, Roman Shpount wrote: > I thought that TURN servers would be provisioned by the java script = (web site) and not the end user, or do we plan to provide an interface = in web browser settings that allows the overwrite for this? Yes, both - in the previous conversations we have agreed to be able to = provide TURN servers both of these ways. We have not yet nailed down = which one takes precedence if both the browser has one configured and = the JS provides one but it seems to me that we need the one the browser = provided TURN server to be higher priority than the JS provided one.=20 From ted.ietf@gmail.com Tue Feb 7 12:24: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 012FF21F86A2 for ; Tue, 7 Feb 2012 12:24:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.928 X-Spam-Level: X-Spam-Status: No, score=-3.928 tagged_above=-999 required=5 tests=[AWL=-0.329, 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 7WNBF7kkdvPj for ; Tue, 7 Feb 2012 12:24:41 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id ECF0521F8658 for ; Tue, 7 Feb 2012 12:24:40 -0800 (PST) Received: by vbbfr13 with SMTP id fr13so5447120vbb.31 for ; Tue, 07 Feb 2012 12:24:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=K2fiFjyXTVd7ddoY28oVarH4iFN2BAjnsu1aKiuTPuU=; b=YE/8DqW9aRjP3MyxYGn0N2tLjOkHY9HmV66HkhFjYxc8JQ+hGcTMyVaWNz5NHo13bi UAsXOD1Nf21KzNfbct01C4O0sDgixDMRB67P+kN8IQF8iGhmsGdAIGULZoqNDfXqEUOB MMJJTXW3f/76TR/LRSBXt5D0X30NCI5n7pDRI= MIME-Version: 1.0 Received: by 10.52.91.196 with SMTP id cg4mr11107208vdb.68.1328646280333; Tue, 07 Feb 2012 12:24:40 -0800 (PST) Received: by 10.52.176.40 with HTTP; Tue, 7 Feb 2012 12:24:40 -0800 (PST) Date: Tue, 7 Feb 2012 12:24:40 -0800 Message-ID: From: Ted Hardie To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [rtcweb] Consensus call on JSEP/ROAP 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, 07 Feb 2012 20:24:42 -0000 During the interim meeting, the attendees discussed the JSEP and ROAP proposals. The chairs also asked the working group to consider whether they might be successfully merged. Because of audio difficulties, there is no recording available. The jabber logs contain a transcription of the discussion by Bernard Aboba and can be found here: http://www.ietf.org/jabber/logs/rtcweb/2012-01-31.html. At the end of the discussion, the chairs asked the attendees to indicate their preferences by standing for one of four positions, which were listed prior to the question being called. The positions were: 1--Don't care whether ROAP or JSEP is the input document for further work in this area 2---Prefer ROAP be the input document for further work 3--Prefer JSEP be the input document for further work 4--Prefer to merge the docs, limiting JSEP to RFC 3264 offer/answer semantics. The results were: 1=9 in room, none in jabber 2=11 in room, 2 in jabber 3=25 in room, 3 in jabber 4=8 in room, none in jabber. Because JSEP supports more than one model of negotiation, choosing 3 is a reversal from previous working group consensus to limit work to the offer/answer model. The chairs are now calling for consensus of the working group on this point. Working group participants who were not present at the interim, please review the input documents if you not have yet done so, and forward your comments to the list. All working group participants are asked to make their points on this topic by February 22nd, so that we have timely input prior to the document deadline for Paris. thanks, Ted Hardie for the Chairs From stephen.botzko@gmail.com Tue Feb 7 12:31: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 BC22F21F875D for ; Tue, 7 Feb 2012 12:31:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KkbxmIpf-+7X for ; Tue, 7 Feb 2012 12:31:26 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id E8CB221F87BA for ; Tue, 7 Feb 2012 12:31:25 -0800 (PST) Received: by yenm3 with SMTP id m3so3678974yen.31 for ; Tue, 07 Feb 2012 12:31:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FFpv9Ylw0KRmkIuvzKupCUh4nBHV00aG31Mp3HnwKyQ=; b=Q/1PrTy6MmCrrVbBR5/RlwQmgUzswF0Xu82CQT6+rhPCYvQgWQp4RIHWyczNShTzOc BYoBY7yBdU8FMUjJcx6d4oMaKBfsTrWx699VwtFvwku+iz0RJe0qVcF8tHKuDAYdS2LR O+87ynhHI2NRfEIY2l0fy9XeyXOPsEkHDjO+Q= MIME-Version: 1.0 Received: by 10.182.182.69 with SMTP id ec5mr7715696obc.48.1328646685393; Tue, 07 Feb 2012 12:31:25 -0800 (PST) Received: by 10.182.150.41 with HTTP; Tue, 7 Feb 2012 12:31:25 -0800 (PST) In-Reply-To: <4F29D2A6.4090802@ericsson.com> References: <4F29D2A6.4090802@ericsson.com> Date: Tue, 7 Feb 2012 15:31:25 -0500 Message-ID: From: Stephen Botzko To: Magnus Westerlund Content-Type: multipart/alternative; boundary=14dae939954fb704b504b865a98d Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Confirming consensus from Interim: Data protocol and security mechanism 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, 07 Feb 2012 20:31:26 -0000 --14dae939954fb704b504b865a98d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Just wondering if the IPR declaration on SCTP ( https://datatracker.ietf.org/ipr/1007/) was taken into account. Regards Stephen Botzko On Wed, Feb 1, 2012 at 7:02 PM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > WG, > > This is a 2 week call for confirming the consensus of the interim > meeting regarding data transport. The WG members not present at the > interim are requested to indicate support or objections on the consensus > from the interim. This email contains two calls related to the data > transport. Please provide any input no later than the 15th of February. > > The jabber logs are pretty well capturing the discussion. Please see > from 00:18:36 in > http://www.ietf.org/jabber/logs/rtcweb/2012-02-01.html > > The first consensus call made was which transport protocol that should > be used. Based on the discussion it was clear that SCTP was favored and > that was confirmed by the consensus call. Where 19 participants > preferred SCTP as the transport protocol for the data channel and 3 > desired something else. The WG declared clear consensus for using SCTP > as the transport protocol for data. Does the WG participants not present > agrees or objects? > > The seconds consensus call was on the order of SCTP and DTLS on top of > UDP. The two alternatives are: SCTP/DTLS/UDP or DTLS/SCTP/UDP. This was > a unanimous consensus, where 18 preferred SCTP/DTLS/UDP, and no for the > other order. Does the WG participants not present agrees or objects? > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --14dae939954fb704b504b865a98d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Just wondering if the IPR declaration on SCTP (https://datatracker.ietf.org/ipr/1007/) was take= n into account.

Regards
Stephen Botzko

On Wed, Feb 1, 2012 at 7:02 PM, Magnus Westerlund <magnus.westerlund@ericsson.c= om> wrote:
WG,

This is a 2 week call for confirming the consensus of the interim
meeting regarding data transport. The WG members not present at the
interim are requested to indicate support or objections on the consensus from the interim. This email contains two calls related to the data
transport. Please provide any input no later than the 15th of February.

The jabber logs are pretty well capturing the discussion. Please see
from 00:18:36 in
http://www.ietf.org/jabber/logs/rtcweb/2012-02-01.html

The first consensus call made was which transport protocol that should
be used. Based on the discussion it was clear that SCTP was favored and
that was confirmed by the consensus call. Where 19 participants
preferred SCTP as the transport protocol for the data channel and 3
desired something else. The WG declared clear consensus for using SCTP
as the transport protocol for data. Does the WG participants not present agrees or objects?

The seconds consensus call was on the order of SCTP and DTLS on top of
UDP. The two alternatives are: SCTP/DTLS/UDP or DTLS/SCTP/UDP. This was
a unanimous consensus, where 18 preferred SCTP/DTLS/UDP, and no for the
other order. Does the WG participants not present agrees or objects?

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287
F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| 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

--14dae939954fb704b504b865a98d-- From ekr@rtfm.com Tue Feb 7 12:41: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 6F5D821F887E for ; Tue, 7 Feb 2012 12:41:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.915 X-Spam-Level: X-Spam-Status: No, score=-102.915 tagged_above=-999 required=5 tests=[AWL=0.062, 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 8k86kkNIpJtL for ; Tue, 7 Feb 2012 12:41:51 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8E46721F887D for ; Tue, 7 Feb 2012 12:41:51 -0800 (PST) Received: by vbbfr13 with SMTP id fr13so5459332vbb.31 for ; Tue, 07 Feb 2012 12:41:51 -0800 (PST) Received: by 10.52.38.10 with SMTP id c10mr11279568vdk.58.1328647311104; Tue, 07 Feb 2012 12:41:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.71.19 with HTTP; Tue, 7 Feb 2012 12:41:11 -0800 (PST) X-Originating-IP: [74.95.2.173] From: Eric Rescorla Date: Tue, 7 Feb 2012 12:41:11 -0800 Message-ID: To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [rtcweb] Glareless adds and 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, 07 Feb 2012 20:41:52 -0000 Dear people who understand SDP and 3264 well. Please bear with me as I ask some probably stupid questions. Here's the first of those stupid questions, but depending on the answer to this one, I may have more later. I'm trying to get my head around the glareless upgrade scenario Justin described in the meeting. Based on slide 23, I think what happens is this. Initial call setup: ALICE BOB 1 o1 = pc.createOffer(null); 2 pc.setLocal(o1, SDP_OFFER); 3 o1 -> 4 pc.setRemote(o1, SDP_OFFER); 5 a1 = pc.createAnswer(o1, null); 6 pc.setLocal(a1, SDP_ANSWER); 7 <- a1 8 pc.setRemote(a1, SDP_ANSWER); At this point Alice does something that needs an add, but there's no glarey stuff, Bob just agrees. And as you suggested, this is something that doesn't require a change in the SDP. If I understood last week's discussion properly (and I could have totally misunderstood), you were saying that this didn't require a real answer from Bob, just an acknowledgement, and so Alice could just reinstall Bob's answer to indicate consent. Did I get that correctly? If so, we have something like this: ALICE BOB 9 pc.addStream(localStream2); 10 o2 = pc.createOffer(null); 11 delta = Diff(pc.localDescription, o2); 12 pc.setLocal(o2); 13 o2 -> 14 pc.setRemote(o2); 15 <- OK 16 pc.setRemote(a1); Does this look right? -Ekr From randell-ietf@jesup.org Tue Feb 7 12:57: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 EA0DF21F85E7 for ; Tue, 7 Feb 2012 12:57:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.408 X-Spam-Level: X-Spam-Status: No, score=-2.408 tagged_above=-999 required=5 tests=[AWL=0.191, 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 7lcsj4+rU8WK for ; Tue, 7 Feb 2012 12:57:27 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id EC8C921F85E6 for ; Tue, 7 Feb 2012 12:57:26 -0800 (PST) Received: from pool-173-49-135-74.phlapa.fios.verizon.net ([173.49.135.74] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Rus6Q-0006q1-6x for rtcweb@ietf.org; Tue, 07 Feb 2012 14:57:26 -0600 Message-ID: <4F318FCE.1000904@jesup.org> Date: Tue, 07 Feb 2012 15:55:42 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F29D2A6.4090802@ericsson.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] Confirming consensus from Interim: Data protocol and security mechanism 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, 07 Feb 2012 20:57:28 -0000 On 2/7/2012 3:31 PM, Stephen Botzko wrote: > Just wondering if the IPR declaration on SCTP > (https://datatracker.ietf.org/ipr/1007/) was taken into account. Serious kitchen-sink IPR notice... They even ding RFC 2168 (URIs). They list RFC 4960, but give no idea what in it is covered. Most of them are in some way related to ENUM or telephony signalling (E.164 and SS7 gatewaying/transport). I have not looked at their patents directly, just the IPR notice. -- Randell Jesup randell-ietf@jesup.org From ted.ietf@gmail.com Tue Feb 7 13:07: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 79BD921F84D2 for ; Tue, 7 Feb 2012 13:07:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.917 X-Spam-Level: X-Spam-Status: No, score=-3.917 tagged_above=-999 required=5 tests=[AWL=-0.318, 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 437I1br5Xdg4 for ; Tue, 7 Feb 2012 13:07:23 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4537A21F8474 for ; Tue, 7 Feb 2012 13:07:22 -0800 (PST) Received: by vbbfr13 with SMTP id fr13so5477089vbb.31 for ; Tue, 07 Feb 2012 13:07:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=TuFDNf52ZOnugXItqSUhm8Opx+Mzc9GpD8suQ0jF+JI=; b=uUu8Da/kb/ObwLvUInopkrmkzEvdGKpYsxjIbdOihMU+3U4gMHws+WkcS8oFR9xzFz 1HfBxEGvkG3o5dRZIcHCRStekKncdZzyKU+vndXpSEaH9ZbwNzBVNJ4nUKJZVC8RVpvG pdP6wKiPSbQy805JY9g6DPsk4nDEXrLxRvNzY= MIME-Version: 1.0 Received: by 10.220.155.196 with SMTP id t4mr13184521vcw.52.1328648841675; Tue, 07 Feb 2012 13:07:21 -0800 (PST) Received: by 10.52.176.40 with HTTP; Tue, 7 Feb 2012 13:07:21 -0800 (PST) Date: Tue, 7 Feb 2012 13:07:21 -0800 Message-ID: From: Ted Hardie To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [rtcweb] Charter reminder 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, 07 Feb 2012 21:07:23 -0000 The chairs wish to remind the working group of this aspect of the WG charter: "This work will be done primarily by using already defined protocols or functionalities. If there is identification of missing protocols or functionalities, such work can be requested to be done in another working group with a suitable charter or by requests for chartering it in this WG or another WG." Further work on signaling that does not fit within the current set of IETF standards, such as proposed in the ROAP and JSEP drafts, would require either rechartering this working group, chartering a new working group or having them adopted within a working with an appropriate charter (most probably mmusic). Ted Hardie for the Chairs From stephen.botzko@gmail.com Tue Feb 7 13:21: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 678D921F87E8 for ; Tue, 7 Feb 2012 13:21:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.765 X-Spam-Level: X-Spam-Status: No, score=-2.765 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, 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 XWAwd9p0NsRh for ; Tue, 7 Feb 2012 13:21:29 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id D48DC21F87CA for ; Tue, 7 Feb 2012 13:21:28 -0800 (PST) Received: by yhkk25 with SMTP id k25so3751078yhk.31 for ; Tue, 07 Feb 2012 13:21:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+eIs4U0b3sP3tMyVv3HgUyRUqAGNQWfZh60hXkCKVvw=; b=Db8dEpk2845C/oZ5y26hGx+mcDfon9aAFbXYCGwZOvUVhlD3djAkJBImISP7ImxuGU 93cLBGfqr0IlR7YWAg4ZffnzB780nMK1a7aGo4LKs9dNeq8S8qHwiDu95fV2/u0Fwpt6 1WK8cBAq+39OTQHoJuP0TnEGuBZMg4Cxz0kBE= MIME-Version: 1.0 Received: by 10.182.8.69 with SMTP id p5mr22791389oba.28.1328649688352; Tue, 07 Feb 2012 13:21:28 -0800 (PST) Received: by 10.182.150.41 with HTTP; Tue, 7 Feb 2012 13:21:28 -0800 (PST) In-Reply-To: <4F318FCE.1000904@jesup.org> References: <4F29D2A6.4090802@ericsson.com> <4F318FCE.1000904@jesup.org> Date: Tue, 7 Feb 2012 16:21:28 -0500 Message-ID: From: Stephen Botzko To: Randell Jesup Content-Type: multipart/alternative; boundary=f46d0444ec4bb4884404b8665ca3 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Confirming consensus from Interim: Data protocol and security mechanism 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, 07 Feb 2012 21:21:29 -0000 --f46d0444ec4bb4884404b8665ca3 Content-Type: text/plain; charset=ISO-8859-1 I haven't looked at the patents either (and don't intend to). However, taking it at face value - it does not offer RF terms. Regards, Stephen Botzko On Tue, Feb 7, 2012 at 3:55 PM, Randell Jesup wrote: > On 2/7/2012 3:31 PM, Stephen Botzko wrote: > >> Just wondering if the IPR declaration on SCTP >> (https://datatracker.ietf.org/**ipr/1007/) >> was taken into account. >> > > Serious kitchen-sink IPR notice... They even ding RFC 2168 (URIs). > > They list RFC 4960, but give no idea what in it is covered. Most of them > are in some way related to ENUM or telephony signalling (E.164 and SS7 > gatewaying/transport). > > I have not looked at their patents directly, just the IPR notice. > > -- > Randell Jesup > randell-ietf@jesup.org > > ______________________________**_________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/**listinfo/rtcweb > --f46d0444ec4bb4884404b8665ca3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I haven't looked at the patents either (and don't intend to).=A0 Ho= wever, taking it at face value -=A0 it does not offer RF terms.

Reg= ards,
Stephen Botzko

On Tue, Feb 7, 20= 12 at 3:55 PM, Randell Jesup <randell-ietf@jesup.org> wrote:
On 2/7/2012 3:31 PM, Steph= en Botzko wrote:
Just wondering if the IPR declaration on SCTP
(https= ://datatracker.ietf.org/ipr/1007/) was taken into account.

Serious kitchen-sink IPR notice... =A0They even ding RFC 2168 (URIs).

They list RFC 4960, but give no idea what in it is covered. =A0Most of them= are in some way related to ENUM or telephony signalling (E.164 and SS7 gat= ewaying/transport).

I have not looked at their patents directly, just the IPR notice.

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

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

--f46d0444ec4bb4884404b8665ca3-- From tim@phonefromhere.com Tue Feb 7 14:40: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 A704621F879D for ; Tue, 7 Feb 2012 14:40:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id quFLhCViIYJL for ; Tue, 7 Feb 2012 14:40:22 -0800 (PST) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA8B21F8799 for ; Tue, 7 Feb 2012 14:40:21 -0800 (PST) Received: from [212.183.128.14] (account tpanton@voxeo.com HELO [192.168.2.2]) by voxeo.com (CommuniGate Pro SMTP 5.3.8) with ESMTPSA id 105762627; Tue, 07 Feb 2012 22:40:19 +0000 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Tim Panton In-Reply-To: Date: Tue, 7 Feb 2012 22:40:16 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ted Hardie X-Mailer: Apple Mail (2.1251.1) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Charter reminder 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, 07 Feb 2012 22:40:22 -0000 On 7 Feb 2012, at 21:07, Ted Hardie wrote: > The chairs wish to remind the working group of this aspect of the WG = charter: >=20 > "This work will be done primarily by using already defined protocols > or functionalities. > If there is identification of missing protocols or functionalities, > such work can be requested > to be done in another working group with a suitable charter or by > requests for chartering it > in this WG or another WG." >=20 > Further work on signaling that does not fit within the current set of > IETF standards, such as proposed > in the ROAP and JSEP drafts, would require either rechartering this > working group, chartering a new > working group or having them adopted within a working with an > appropriate charter (most probably mmusic). >=20 > Ted Hardie for the Chairs Only pre-existing IETF documents acceptable here. That being the case I think we had better take a look at rfc5456 since = it meets the bulk of the requirements expressed in the charter. Tim. From ted.ietf@gmail.com Tue Feb 7 14:48: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 CDE8E21F86A8 for ; Tue, 7 Feb 2012 14:48:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.906 X-Spam-Level: X-Spam-Status: No, score=-3.906 tagged_above=-999 required=5 tests=[AWL=-0.307, 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 t+fcjdmqBIe7 for ; Tue, 7 Feb 2012 14:48:43 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 325B621F86A2 for ; Tue, 7 Feb 2012 14:48:24 -0800 (PST) Received: by vbbfr13 with SMTP id fr13so5544764vbb.31 for ; Tue, 07 Feb 2012 14:48:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=X7rkK2/44PWvgh+ThOWh09ltxxExaf63dKl8BOEETJo=; b=f27gypkgi8GnGKga/3jFco3HY13EeY4STuVhlLTJwRckpeMs/36qFSsOC7gIKm5xge ONl+ha4w2ZXXESI0mBfcZ77MUxCQ5JbexOanZIsde0f726Xy2lzQQnLuTbydkpRXEdiE ykCiiVMBi0eIBEAZJBz9qbGsa6Yh5tgcP5mh0= MIME-Version: 1.0 Received: by 10.52.91.196 with SMTP id cg4mr11274124vdb.68.1328654903627; Tue, 07 Feb 2012 14:48:23 -0800 (PST) Received: by 10.52.176.40 with HTTP; Tue, 7 Feb 2012 14:48:23 -0800 (PST) In-Reply-To: References: Date: Tue, 7 Feb 2012 14:48:23 -0800 Message-ID: From: Ted Hardie To: Tim Panton Content-Type: text/plain; charset=ISO-8859-1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Charter reminder 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, 07 Feb 2012 22:48:46 -0000 On Tue, Feb 7, 2012 at 2:40 PM, Tim Panton wrote: > > On 7 Feb 2012, at 21:07, Ted Hardie wrote: > Only pre-existing IETF documents acceptable here. > I think that's a little too terse a summary. The IETF charters working groups with a defined scope. If a working group decides that work needs doing that doesn't fit within that scope the choices almost always boil down to: increase the scope; find an existing group for which it is in scope and go there for that piece of work; charter a new group with that scope. The chairs want to remind folks of that because work outside our currently defined scope is being proposed. We are not saying "don't do the work". Hope that clears up any confusion, Ted From fluffy@iii.ca Tue Feb 7 15:24:55 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 315D221F877D for ; Tue, 7 Feb 2012 15:24:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.993 X-Spam-Level: X-Spam-Status: No, score=-2.993 tagged_above=-999 required=5 tests=[AWL=-0.394, 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 XSA9xsFTOQtD for ; Tue, 7 Feb 2012 15:24:54 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6CB21F8778 for ; Tue, 7 Feb 2012 15:24:32 -0800 (PST) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 7F46822E1F4; Tue, 7 Feb 2012 18:24:26 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Tue, 7 Feb 2012 16:24:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: rtcweb@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [rtcweb] Charter reminder 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, 07 Feb 2012 23:24:55 -0000 On Feb 7, 2012, at 3:48 PM, Ted Hardie wrote: > On Tue, Feb 7, 2012 at 2:40 PM, Tim Panton = wrote: >>=20 >> On 7 Feb 2012, at 21:07, Ted Hardie wrote: >=20 >> Only pre-existing IETF documents acceptable here. >>=20 > I think that's a little too terse a summary. The IETF charters > working groups with a defined scope. > If a working group decides that work needs doing that doesn't fit > within that scope > the choices almost always boil down to: increase the scope; find an > existing group > for which it is in scope and go there for that piece of work; charter > a new group with that scope. The chairs > want to remind folks of that because work outside our currently > defined scope is being proposed. We > are not saying "don't do the work". >=20 > Hope that clears up any confusion, >=20 > Ted >=20 +1 Ted and like to add...=20 We are already have several topics in this WG where we taken some work = that needed to get done, and sent it off to some more appropriate = working group.=20 From harald@alvestrand.no Tue Feb 7 18:37: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 EFCB111E80A6 for ; Tue, 7 Feb 2012 18:37:12 -0800 (PST) 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 CHOu8J2gGwOY for ; Tue, 7 Feb 2012 18:37:12 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 023B011E80A5 for ; Tue, 7 Feb 2012 18:37:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CFD1C39E090 for ; Wed, 8 Feb 2012 03:37:10 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F32fMzgZXnp9 for ; Wed, 8 Feb 2012 03:37:09 +0100 (CET) Received: from [192.168.6.21] (unknown [65.91.54.2]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 3BAC539E01E for ; Wed, 8 Feb 2012 03:37:09 +0100 (CET) Message-ID: <4F31DFD2.6090302@alvestrand.no> Date: Tue, 07 Feb 2012 18:37:06 -0800 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: rtcweb@ietf.org References: <837E772D16C77141BFA5FEC3F30487FF525B89EC@PACDCEXMB02.cable.comcast.com> In-Reply-To: <837E772D16C77141BFA5FEC3F30487FF525B89EC@PACDCEXMB02.cable.comcast.com> Content-Type: multipart/alternative; boundary="------------050401080205040103050100" Subject: Re: [rtcweb] Incoming Call for RTCWeb using Websocket extention or HTTP custom-make signaling protocol 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, 08 Feb 2012 02:37:13 -0000 This is a multi-part message in MIME format. --------------050401080205040103050100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit On 02/06/2012 11:42 AM, Khan, Sohel wrote: > > My question pertains to RTCWeb Incoming call. > > Please assume for this discussion, RTCWeb system uses Websocket > extention or HTTP custom-make signaling protocol. > > Also, please assume that a NAT or multiple NAT exist between the > RTCWeb server and the RTC Web client (Receiver). > > Here, the sender of the call is Alice and receiver of the call is Bob. > > We would like to discuss the signaling protocol between the RTC Web > Server to Bob > > |RTC Web Server|---à|NAT|-àRTC Web-Client (receiver). > Please read draft-ietf-rtcweb-overview-02 section 3 - the WG decided some time ago that the precise protocol for communicating between the Web server (or the SIP server in your other note) was out of scope for this standardization effort; the standardized parts are limited to the syntax and semantics of the data exchanged over the peer-to-peer connection (media path) and the semantics that are exposed through the API exposed by the browser. Discussion of protocols for signalling should be taken as examples, not as candidates for standardization in this group. Harald --------------050401080205040103050100 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 02/06/2012 11:42 AM, Khan, Sohel wrote:

My question pertains to RTCWeb Incoming call.

Please assume for this discussion,  RTCWeb  system uses Websocket extention or HTTP custom-make signaling protocol.

Also, please assume that a NAT or multiple NAT exist between the RTCWeb server and the RTC  Web client (Receiver).

Here, the sender of the call is Alice and receiver of the call is Bob.

We would like to discuss the signaling protocol between the RTC Web Server to Bob

 

|RTC Web Server|---à|NAT|-àRTC Web-Client (receiver).


Please read draft-ietf-rtcweb-overview-02 section 3 - the WG decided some time ago that the precise protocol for communicating between the Web server (or the SIP server in your other note) was out of scope for this standardization effort; the standardized parts are limited to the syntax and semantics of the data exchanged over the peer-to-peer connection (media path) and the semantics that are exposed through the API exposed by the browser.

Discussion of protocols for signalling should be taken as examples, not as candidates for standardization in this group.

                Harald

--------------050401080205040103050100-- From matthew.kaufman@skype.net Tue Feb 7 21:46: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 D8BA921F8552 for ; Tue, 7 Feb 2012 21:46:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWi-w-rmg74o for ; Tue, 7 Feb 2012 21:46:27 -0800 (PST) Received: from DB3EHSOBE001.bigfish.com (db3ehsobe002.messaging.microsoft.com [213.199.154.140]) by ietfa.amsl.com (Postfix) with ESMTP id CFA4821F8551 for ; Tue, 7 Feb 2012 21:46:26 -0800 (PST) Received: from mail23-db3-R.bigfish.com (10.3.81.226) by DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id 14.1.225.23; Wed, 8 Feb 2012 05:46:24 +0000 Received: from mail23-db3 (localhost [127.0.0.1]) by mail23-db3-R.bigfish.com (Postfix) with ESMTP id 1ACA8603DD; Wed, 8 Feb 2012 05:46:24 +0000 (UTC) X-SpamScore: -7 X-BigFish: VS-7(z4c5Ozzz1202hzzz2fh87h2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail23-db3: domain of skype.net designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=matthew.kaufman@skype.net; helo=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; X-FB-DOMAIN-IP-MATCH: fail Received: from mail23-db3 (localhost.localdomain [127.0.0.1]) by mail23-db3 (MessageSwitch) id 1328679982437029_16192; Wed, 8 Feb 2012 05:46:22 +0000 (UTC) Received: from DB3EHSMHS006.bigfish.com (unknown [10.3.81.233]) by mail23-db3.bigfish.com (Postfix) with ESMTP id 5E68DC0048; Wed, 8 Feb 2012 05:46:22 +0000 (UTC) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS006.bigfish.com (10.3.87.106) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 8 Feb 2012 05:46:21 +0000 Received: from TK5EX14MBXC274.redmond.corp.microsoft.com ([169.254.3.210]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0247.005; Tue, 7 Feb 2012 21:46:21 -0800 From: Matthew Kaufman To: Ted Hardie , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Charter reminder Thread-Index: AQHM5dyEQpQgASSUEU+sSyB399ldvZYyfdxw Date: Wed, 8 Feb 2012 05:46:20 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [rtcweb] Charter reminder 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, 08 Feb 2012 05:46:28 -0000 Does the charter not include drafting a requirements document to give to W3= C that might include requirements of the API? Thus any description of a sig= naling method that produces as its conclusion a set of API requirements sho= uld be in scope. Matthew Kaufman From igor.faynberg@alcatel-lucent.com Tue Feb 7 22:15: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 8F79921F874A for ; Tue, 7 Feb 2012 22:15:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.099 X-Spam-Level: X-Spam-Status: No, score=-9.099 tagged_above=-999 required=5 tests=[AWL=1.500, 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 NKahOK0gyV2L for ; Tue, 7 Feb 2012 22:15:38 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id E9A0B21F8748 for ; Tue, 7 Feb 2012 22:15:37 -0800 (PST) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q186Fbkd007893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 8 Feb 2012 00:15:37 -0600 (CST) 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 q186FaRx023829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 8 Feb 2012 00:15:37 -0600 Received: from [135.244.18.88] (faynberg.lra.lucent.com [135.244.18.88]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q186FZO9000202; Wed, 8 Feb 2012 00:15:35 -0600 (CST) Message-ID: <4F321307.5060809@alcatel-lucent.com> Date: Wed, 08 Feb 2012 01:15:35 -0500 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.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: Re: [rtcweb] Charter reminder 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, 08 Feb 2012 06:15:38 -0000 No problem with the reminder, but I read it then that no consensus on JSEP vs ROAP is to be determined at the moment. Am I right? (I am still trying to understand where we are post interim.) Igor On 2/7/2012 4:07 PM, Ted Hardie wrote: > The chairs wish to remind the working group of this aspect of the WG charter: > > "This work will be done primarily by using already defined protocols > or functionalities. > If there is identification of missing protocols or functionalities, > such work can be requested > to be done in another working group with a suitable charter or by > requests for chartering it > in this WG or another WG." > > Further work on signaling that does not fit within the current set of > IETF standards, such as proposed > in the ROAP and JSEP drafts, would require either rechartering this > working group, chartering a new > working group or having them adopted within a working with an > appropriate charter (most probably mmusic). > > Ted Hardie for the Chairs > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From randell-ietf@jesup.org Wed Feb 8 08:29: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 BC4D621F8762 for ; Wed, 8 Feb 2012 08:29:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.418 X-Spam-Level: X-Spam-Status: No, score=-2.418 tagged_above=-999 required=5 tests=[AWL=0.181, 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 0qxRo+a3T5RX for ; Wed, 8 Feb 2012 08:29:20 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 951D621F875B for ; Wed, 8 Feb 2012 08:29:07 -0800 (PST) Received: from pool-173-49-135-74.phlapa.fios.verizon.net ([173.49.135.74] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RvAOI-000331-Pt for rtcweb@ietf.org; Wed, 08 Feb 2012 10:29:06 -0600 Message-ID: <4F32A269.4070503@jesup.org> Date: Wed, 08 Feb 2012 11:27:21 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.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-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] Charter reminder 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, 08 Feb 2012 16:29:20 -0000 On 2/7/2012 4:07 PM, Ted Hardie wrote: > The chairs wish to remind the working group of this aspect of the WG charter: > > "This work will be done primarily by using already defined protocols > or functionalities. > If there is identification of missing protocols or functionalities, > such work can be requested > to be done in another working group with a suitable charter or by > requests for chartering it > in this WG or another WG." > > Further work on signaling that does not fit within the current set of > IETF standards, such as proposed > in the ROAP and JSEP drafts, would require either rechartering this > working group, chartering a new > working group or having them adopted within a working with an > appropriate charter (most probably mmusic). > > Ted Hardie for the Chairs Ok. You may be right on this (hopefully, since you're a chair). :-) I'll go out on a rhetorical limb here... And not I'm not an expert on what's in the IETF's domain or not. Since both ROAP and JSEP do not define on-the-wire protocols, one could make an argument that ROAP and JSEP are both JS APIs within the charter of W3C, and not the IETF. They both leverage SDP, of course, but neither specifies what goes onto the wire. It could all get converted to H.323, for that matter, or something totally different with no SDP per-se. So to some extent (mostly how you resolve the local/remote SDPs) it may fall into the IETF; to a large extent it's either explicitly in the app's domain, or it's the JS API and standards for how to use it, which seems like they would fall into the W3C's domain. In reality, this all straddles the divide (and is much more on the W3C side than if we had decided to define/select a direct on-the-wire protocol). That said - we (IETF) can define an RFC for how to exchange SDPs and resolve their values, which amounts to the equivalent to JSEP, without defining the JS API itself in our RFC. This implies that eventually we should split JSEP into an RFC for how to resolve the SDPs, and a W3C API we propose for doing it (i.e. Kaufman's comment). ROAP, since it was based on RFC 3264, would not in my mind need a new RFC for SDP negotiation, just a W3C API. For both we would probably specify which SDP options are allowed. (*Please* note I don't mean this to engender a long discussion of how to split them or if I'm correct about the dividing line - I'm just pointing out we may not need to spin off as much as some might think.) We have enough long discussions already. :-( If we need to spin something off for standardization or expand our charter - fine, let's do that. Let's just be careful not to massively expand our schedule, as the market won't wait for us, and it's hard to put genies back in bottles. (Speaking as an individual.) Quoting Ted (and zillions of others): the perfect is the enemy of the good. -- Randell Jesup randell-ietf@jesup.org From xavier.marjou@gmail.com Wed Feb 8 08:44: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 304A121F8624 for ; Wed, 8 Feb 2012 08:44:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03CZqY6nh9mu for ; Wed, 8 Feb 2012 08:44:35 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9509821F8617 for ; Wed, 8 Feb 2012 08:44:17 -0800 (PST) Received: by obbwd15 with SMTP id wd15so1246318obb.31 for ; Wed, 08 Feb 2012 08:44:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=qkWOJeGCjeozQwPIFzkG9TbBt9Jujx20D9pXvcgr+k0=; b=x8M73tlbgWXbx8Ay9mnI1rHFkzB3K8QnzDsNr7mJqvgfzeAgk0wU7XMhG1astfDeT6 p86m2M1fGVy1uw5g0WMkeVgH0nbyG9fewI4cbWf+x6PAcKc3xjgvB0fskBLak+h1iiw2 rVm0XxAmvk1eDksDi+7aDC3mJ4Qs7I1O2fuJY= MIME-Version: 1.0 Received: by 10.182.88.70 with SMTP id be6mr26441753obb.36.1328719457280; Wed, 08 Feb 2012 08:44:17 -0800 (PST) Received: by 10.60.2.70 with HTTP; Wed, 8 Feb 2012 08:44:17 -0800 (PST) In-Reply-To: References: Date: Wed, 8 Feb 2012 17:44:17 +0100 Message-ID: From: Xavier Marjou To: Eric Rescorla Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Glareless adds and 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, 08 Feb 2012 16:44:36 -0000 I won't pretend that I understand all the cases well, but here is a tentative to answer the question. RFC3264 states that The agent receiving the offer MAY generate an answer, or it MAY reject the offer. The means for rejecting an offer are dependent on the higher layer protocol. The offer/answer exchange is atomic; if the answer is rejected, the session reverts to the state prior to the offer (which may be absence of a session). At any time, either agent MAY generate a new offer that updates the session. However, it MUST NOT generate a new offer if it has received an offer which it has not yet answered or rejected. Furthermore, it MUST NOT generate a new offer if it has generated a prior offer for which it has not yet received an answer or a rejection. If an agent receives an offer after having sent one, but before receiving an answer to it, this is considered a "glare" condition. I don't see any text indicating in this RFC, in particular in sections 4 and 8, that the agent receiving an offer can accept it without sending an SDP answer to the offerer. Let's suppose it would be possible, as depicted in your flow 15: a hypothetical o3=A0offer from Alice would not be possible according to the above mentioned text. So maybe a more precise sentence for RFC3264 could have been The agent receiving the offer MUST either generate an answer, or reject the offer. Cheers, Xavier PS: RFC6337 discusses the tricky cases of SDP offer-answer, but I don't remember anything on that topic. On Tue, Feb 7, 2012 at 9:41 PM, Eric Rescorla wrote: > > Dear people who understand SDP and 3264 well. Please bear with me > as I ask some probably stupid questions. Here's the first of those > stupid questions, but depending on the answer to this one, I > may have more later. > > I'm trying to get my head around the glareless upgrade scenario Justin > described in the meeting. Based on slide 23, I think what happens is > this. > > Initial call setup: > =A0 =A0ALICE =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0BOB > 1 =A0 o1 =3D pc.createOffer(null); > 2 =A0 pc.setLocal(o1, SDP_OFFER); > 3 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 o1 -> > 4 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0pc.setRemote(o1, SDP_OFFER); > 5 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0a1 =3D pc.createAnswer(o1, null); > 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0pc.setLocal(a1, SDP_ANSWER); > 7 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <- a1 > 8 =A0 =A0pc.setRemote(a1, SDP_ANSWER); > > > > At this point Alice does something that needs an add, but there's no > glarey stuff, Bob just agrees. And as you suggested, this is something > that doesn't require a change in the SDP. If I understood last week's > discussion properly (and I could have totally misunderstood), you were > saying that this didn't require a real answer from Bob, just an > acknowledgement, and so Alice could just reinstall Bob's answer to > indicate consent. Did I get that correctly? =A0If so, we have something > like this: > > =A0 =A0ALICE =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0BOB > 9 =A0 pc.addStream(localStream2); > 10 =A0o2 =3D pc.createOffer(null); > 11 =A0delta =3D Diff(pc.localDescription, o2); > 12 =A0pc.setLocal(o2); > 13 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 o2 -> > 14 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0pc.setRemote(o2); > 15 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <- OK > 16 =A0pc.setRemote(a1); > > Does this look right? > > -Ekr > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From ted.ietf@gmail.com Wed Feb 8 09:38: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 5961921F871E for ; Wed, 8 Feb 2012 09:38:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.896 X-Spam-Level: X-Spam-Status: No, score=-3.896 tagged_above=-999 required=5 tests=[AWL=-0.297, 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 fCDxd9uDVTfH for ; Wed, 8 Feb 2012 09:38:50 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 86A4021F871B for ; Wed, 8 Feb 2012 09:38:50 -0800 (PST) Received: by vcbfk14 with SMTP id fk14so588684vcb.31 for ; Wed, 08 Feb 2012 09:38:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=DeMn8dbXI2TgMkoSFKPAk6u/xBWqI/lYlTKWGLO2iJo=; b=dxYX9qAkv0F74VN9ekKMuRpf3M7VeaELPeeFybwPpbrqrEY9XuBjqEdySBjjjcHEUr ZChvLGyJLmePd2L0GCXRMCPnzf4ckKTmOwIGoIHbwTiaI0vAhc+VxHEwl9710lfMjJVM XkDPH2D0tuP+E+C3izPhGznRV7fjHme4YRM9I= MIME-Version: 1.0 Received: by 10.52.88.235 with SMTP id bj11mr12599924vdb.119.1328722730087; Wed, 08 Feb 2012 09:38:50 -0800 (PST) Received: by 10.52.31.68 with HTTP; Wed, 8 Feb 2012 09:38:50 -0800 (PST) In-Reply-To: <4F321307.5060809@alcatel-lucent.com> References: <4F321307.5060809@alcatel-lucent.com> Date: Wed, 8 Feb 2012 09:38:50 -0800 Message-ID: From: Ted Hardie 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] Charter reminder 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, 08 Feb 2012 17:38:51 -0000 On Tue, Feb 7, 2012 at 10:15 PM, Igor Faynberg wrote: > > > No problem with the reminder, but I read it then that no consensus on JSE= P > vs ROAP is to be determined at the moment. =A0Am I right? > > (I am still trying to understand where we are post interim.) > > Igor The consensus call is on going; this is a general reminder about the current charter scope. Ted > > > > On 2/7/2012 4:07 PM, Ted Hardie wrote: >> >> The chairs wish to remind the working group of this aspect of the WG >> charter: >> >> "This work will be done primarily by using already defined protocols >> or functionalities. >> If there is identification of missing protocols or functionalities, >> such work can be requested >> to be done in another working group with a suitable charter or by >> requests for chartering it >> in this WG or another WG." >> >> Further work on signaling that does not fit within the current set of >> IETF standards, such as proposed >> in the ROAP and JSEP drafts, would require either rechartering this >> working group, chartering a new >> working group or having them adopted within a working with an >> appropriate charter (most probably mmusic). >> >> Ted Hardie for the Chairs >> _______________________________________________ >> 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 Wed Feb 8 09:56: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 6101F21F86DD for ; Wed, 8 Feb 2012 09:56:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.887 X-Spam-Level: X-Spam-Status: No, score=-3.887 tagged_above=-999 required=5 tests=[AWL=-0.288, 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 0gYEvyi8Yyc4 for ; Wed, 8 Feb 2012 09:56:42 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id B54B621F8698 for ; Wed, 8 Feb 2012 09:56:42 -0800 (PST) Received: by vcbfk14 with SMTP id fk14so603087vcb.31 for ; Wed, 08 Feb 2012 09:56:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=8uR6qkHTVljwnLh4GED8pWBQEM6LH99rmoR/TKDHPRs=; b=ST/YKyyU0GQVr/PoQSuxXw9bJGEtanji99YB1aLxntFUbCcQUTYHTwQmmTndAOvn2y dbPX3Qgx2IH9X7jx+ZDB0d82VrJz2bDc1Sjd2LEur+iBIZTqx9CEBFDhx82sPYSq2gxn 9EM+xVVfFbrWPqj9nWRBSC5qxoGvNUxFnSNEI= MIME-Version: 1.0 Received: by 10.220.39.7 with SMTP id d7mr14877729vce.62.1328723802279; Wed, 08 Feb 2012 09:56:42 -0800 (PST) Received: by 10.52.31.68 with HTTP; Wed, 8 Feb 2012 09:56:42 -0800 (PST) In-Reply-To: <4F32A269.4070503@jesup.org> References: <4F32A269.4070503@jesup.org> Date: Wed, 8 Feb 2012 09:56:42 -0800 Message-ID: From: Ted Hardie To: Randell Jesup , Matthew Kaufman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Charter reminder 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, 08 Feb 2012 17:56:43 -0000 Hi Randell, Matthew, Since you both had questions on the same point, I piled the answers into one message. On Wed, Feb 8, 2012 at 8:27 AM, Randell Jesup wrot= e: > Since both ROAP and JSEP do not define on-the-wire protocols, one could m= ake > an argument that ROAP and JSEP are both JS APIs within the charter of W3C= , > and not the IETF. > Yes. If they specify APIs only, they are either recommendations from the I= ETF to the W3C on the API or documents that might move into the W3C. But.... > They both leverage SDP, of course, if they require *new* work related to SDP, either in syntax or context-specific semantics for existing syntax, that work has to be in the IETF, and it has to recognize the charter scope. The working group has previously agreed that creating something other than = SDP would be too slow, given that it would have to have at least all of the features of SDP that aren't multicast-specific in order to meet its interoperablity goa= ls (and given a history of attempts at it that do not feature a lot of success= ). Without consulting the other chairs, I couldn't call consensus on this, but at least so far I have not heard anything that I would say challenges that previous decision. My personal opinion is that any API that can provide a mapping to what the equivalent SDP incantation would be is going to find the interoperability i= ssues much easier to tackle. If the entire API can be mapped into existing SDP incantations (whether offer/answer or declarative), then the work will fit entirely within our existing charter. That is likely the fastest way forwa= rd, though it may still require a way to show context (offer/answer vs. declara= tive) that has historical been inferred from using protocol. An additional opinion, completely free for the asking and at no cost to you= , is that new syntax for new semantics will have a lower total cost of introduct= ion, compared to re-using existing syntax with context-specific semantics. Ther= e are certainly contrary examples, but, hey, everybody's got an opinion and t= hat one is mine. > > If we need to spin something off for standardization or expand our charte= r - > fine, let's do that. =A0Let's just be careful not to massively expand our > schedule, as the market won't wait for us, and it's hard to put genies ba= ck > in bottles. I agree on both points, at least wearing my personal hat. regards, Ted =A0(Speaking as an individual.) =A0Quoting Ted (and zillions of > others): the perfect is the enemy of the good. > > -- > Randell Jesup > randell-ietf@jesup.org From juberti@google.com Wed Feb 8 12:57: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 AC9B621F84FD for ; Wed, 8 Feb 2012 12:57:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.767 X-Spam-Level: X-Spam-Status: No, score=-102.767 tagged_above=-999 required=5 tests=[AWL=0.209, 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 Puwb7LeWbR-8 for ; Wed, 8 Feb 2012 12:57:46 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 04E2521F8319 for ; Wed, 8 Feb 2012 12:57:41 -0800 (PST) Received: by yenm3 with SMTP id m3so604797yen.31 for ; Wed, 08 Feb 2012 12:57:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:from:date:message-id:subject:to:x-system-of-record :content-type; bh=wE2QNW/koQZ6FDQzePvyJGYwOh0ffD44CBJnfM/wzME=; b=DOWp9j7hBQq2OzTxwn+kYXBxy80Ruq4CU8Eyy/a6x6QpItDcL943BmWzd2Oo++PRIq Ep22ysiy9trPYG1oo94d/ExWBtE4yXEVNNQDafTvBMVsM4Baytj7wXj450++M6SoFNtG qqUiBaltClSOz+7Q5HdGvzpxHxsO9VkzjjOkk= Received: by 10.50.153.198 with SMTP id vi6mr36368952igb.30.1328734661442; Wed, 08 Feb 2012 12:57:41 -0800 (PST) Received: by 10.50.153.198 with SMTP id vi6mr36368937igb.30.1328734661365; Wed, 08 Feb 2012 12:57:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.85.132 with HTTP; Wed, 8 Feb 2012 12:57:21 -0800 (PST) From: Justin Uberti Date: Wed, 8 Feb 2012 15:57:21 -0500 Message-ID: To: rtcweb@ietf.org, public-webrtc@w3.org X-System-Of-Record: true Content-Type: multipart/alternative; boundary=e89a8f22c6817dd08604b87a2527 Subject: [rtcweb] New JSEP draft posted 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, 08 Feb 2012 20:57:46 -0000 --e89a8f22c6817dd08604b87a2527 Content-Type: text/plain; charset=UTF-8 Now available at http://www.ietf.org/id/draft-uberti-rtcweb-jsep-01.txt Includes changes based on implementation feedback, and I believe it addresses most of the concerns raised in last week's interim meetings: - Initial documentation provided for each API call, and what state changes it causes - More examples, including a complete basic sample application - Simplified approach to trickle candidate handling - Resolved concerns about how to separate SDP attributes into media / transport - Provided encapsulation for SDP blobs and ICE candidate lines, in the event we want to change encodings or provide helper functions for JS - Provided mechanism for limiting candidates to TURN-only - Resolved several implementation issues I have not yet addressed the non-overlapping codec concern mentioned in the interim meeting. I think there are ways of handling this either in the application or the implementation, but I wanted to get this -01 out first for feedback. --e89a8f22c6817dd08604b87a2527 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Now available at http://www.ietf.org/id/draft-uberti-rtcweb-jsep-01.txt
Includes changes based on implementation feedback, and I believ= e it addresses most of the concerns raised in last week's interim meeti= ngs:
- Initial documentation provided for each API call, and what state cha= nges it causes
- More examples, including a complete basic sample= application
- Simplified approach to trickle candidate handling<= /div>
- Resolved concerns about how to separate SDP attributes into media / = transport
- Provided encapsulation for SDP blobs and ICE candidat= e lines, in the event we want to change encodings or provide helper functio= ns for JS
- Provided mechanism for limiting candidates to TURN-only
- = Resolved several implementation issues

I have not = yet addressed the non-overlapping codec concern mentioned in the interim me= eting. I think there are ways of handling this either in the application or= the implementation, but I wanted to get this -01 out first for feedback. --e89a8f22c6817dd08604b87a2527-- From Jim.Barnett@genesyslab.com Thu Feb 9 07:27: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 2B0BD21F84B9 for ; Thu, 9 Feb 2012 07:27:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_29=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 wCBb4mnoo2Oy for ; Thu, 9 Feb 2012 07:27:26 -0800 (PST) Received: from relay-out1.wc.genesyslab.com (relay-out1.wc.genesyslab.com [198.49.180.223]) by ietfa.amsl.com (Postfix) with ESMTP id 6B9BD21F8319 for ; Thu, 9 Feb 2012 07:27:26 -0800 (PST) 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 q19FRKDB028566; Thu, 9 Feb 2012 07:27:20 -0800 (PST) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 9 Feb 2012 07:27:20 -0800 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_01CCE73F.509C59F0" Date: Thu, 9 Feb 2012 07:26:54 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] New JSEP draft posted Thread-Index: AczmpFNzGFi+YT0dTlGt55Q+VHMdFQAmN6sg References: From: "Jim Barnett" To: "Justin Uberti" , , X-OriginalArrivalTime: 09 Feb 2012 15:27:20.0594 (UTC) FILETIME=[50789F20:01CCE73F] Subject: Re: [rtcweb] New JSEP draft posted 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, 09 Feb 2012 15:27:27 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCE73F.509C59F0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SnVzdGluLA0KDQpXaGF0IGhhcHBlbnMgaWYgdGhlIGFwcGxpY2F0aW9uIEphdmFTY3JpcHQgbW9k aWZpZXMgdGhlIG9mZmVyPyAgVGFrZSB0aGUgb2ZmZXIgZ2VuZXJhdGlvbiBpbiBleGFtcGxlIDcu MToNCg0KMS4gIE9mZmVyZXJKUy0+T2ZmZXJlclVBOiAgIHBjID0gbmV3IFBlZXJDb25uZWN0aW9u KCk7DQoNCjIuICBPZmZlcmVySlMtPk9mZmVyZXJVQTogICBwYy5hZGRTdHJlYW0obG9jYWxTdHJl YW0sIG51bGwpOw0KDQozLiAgT2ZmZXJlckpTLT5PZmZlcmVyVUE6ICAgcGMuc3RhcnRJY2UoKTsN Cg0KNC4gIE9mZmVyZXJVQS0+T2ZmZXJlckpTOiAgIGljZUNhbGxiYWNrKGNhbmRpZGF0ZSwgZmFs c2UpOw0KDQo1LiAgT2ZmZXJlckpTLT5PZmZlcmVyVUE6ICAgb2ZmZXIgPSBwYy5jcmVhdGVPZmZl cihudWxsKTsNCg0KNi4gIE9mZmVyZXJKUy0+T2ZmZXJlclVBOiAgIHBjLnNldExvY2FsRGVzY3Jp cHRpb24oU0RQX09GRkVSLCBvZmZlci50b1NkcCgpKTsNCg0KNy4gIE9mZmVyZXJKUy0+QW5zd2Vy ZXJKUzogIHsidHlwZSI6Ik9GRkVSIiwgInNkcCI6IjxvZmZlcj4ifQ0KDQogDQoNCkNvdWxkIHRo ZSBKUyBtb2RpZnkgdGhlIG9mZmVyIGJldHdlZW4gc3RlcHMgNSBhbmQgNiBvciBiZXR3ZWVuIHN0 ZXBzIDYgYW5kIDc/ICBGb3IgZXhhbXBsZSwgYmV0d2VlbiBzdGVwcyA1IGFuZCA2LCBjb3VsZCB0 aGUgSlMgYWRkIGEgc3RyZWFtIGZvciB3aGljaCBwYy5hZGRTdHJlYW0gaGFkIG5vdCBiZWVuIGNh bGxlZCBwcmV2aW91c2x5PyAgV291bGQgc2V0TG9jYWxEZXNjcmlwdGlvbiBtYWtlIHRoZSBuZWNl c3NhcnkgbW9kaWZpY2F0aW9ucyBpbiB0aGF0IGNhc2U/ICAgIFdoYXQgYWJvdXQgY2hhbmdlcyBh ZnRlciBzZXRMb2NhbERlc2NyaXB0aW9uIGhhcyBiZWVuIGNhbGxlZD8gIEFyZSB0aGV5IG5vdCBh bGxvd2VkPyAgSWYgdGhleSBhcmUgYWxsb3dlZCwgaG93IGRvZXMgdGhlIHBlZXIgY29ubmVjdGlv biBrbm93IHdoYXQgdG8gZXhwZWN0IGZyb20gdGhlIG90aGVyIHNpZGU/ICANCg0KIA0KDQotICAg ICAgICAgIEppbQ0KDQogDQoNCiANCg0KIA0KDQpGcm9tOiBydGN3ZWItYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSnVzdGluIFVi ZXJ0aQ0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAwOCwgMjAxMiAzOjU3IFBNDQpUbzogcnRj d2ViQGlldGYub3JnOyBwdWJsaWMtd2VicnRjQHczLm9yZw0KU3ViamVjdDogW3J0Y3dlYl0gTmV3 IEpTRVAgZHJhZnQgcG9zdGVkDQoNCiANCg0KTm93IGF2YWlsYWJsZSBhdCBodHRwOi8vd3d3Lmll dGYub3JnL2lkL2RyYWZ0LXViZXJ0aS1ydGN3ZWItanNlcC0wMS50eHQNCg0KIA0KDQpJbmNsdWRl cyBjaGFuZ2VzIGJhc2VkIG9uIGltcGxlbWVudGF0aW9uIGZlZWRiYWNrLCBhbmQgSSBiZWxpZXZl IGl0IGFkZHJlc3NlcyBtb3N0IG9mIHRoZSBjb25jZXJucyByYWlzZWQgaW4gbGFzdCB3ZWVrJ3Mg aW50ZXJpbSBtZWV0aW5nczoNCg0KLSBJbml0aWFsIGRvY3VtZW50YXRpb24gcHJvdmlkZWQgZm9y IGVhY2ggQVBJIGNhbGwsIGFuZCB3aGF0IHN0YXRlIGNoYW5nZXMgaXQgY2F1c2VzDQoNCi0gTW9y ZSBleGFtcGxlcywgaW5jbHVkaW5nIGEgY29tcGxldGUgYmFzaWMgc2FtcGxlIGFwcGxpY2F0aW9u DQoNCi0gU2ltcGxpZmllZCBhcHByb2FjaCB0byB0cmlja2xlIGNhbmRpZGF0ZSBoYW5kbGluZw0K DQotIFJlc29sdmVkIGNvbmNlcm5zIGFib3V0IGhvdyB0byBzZXBhcmF0ZSBTRFAgYXR0cmlidXRl cyBpbnRvIG1lZGlhIC8gdHJhbnNwb3J0DQoNCi0gUHJvdmlkZWQgZW5jYXBzdWxhdGlvbiBmb3Ig U0RQIGJsb2JzIGFuZCBJQ0UgY2FuZGlkYXRlIGxpbmVzLCBpbiB0aGUgZXZlbnQgd2Ugd2FudCB0 byBjaGFuZ2UgZW5jb2RpbmdzIG9yIHByb3ZpZGUgaGVscGVyIGZ1bmN0aW9ucyBmb3IgSlMNCg0K LSBQcm92aWRlZCBtZWNoYW5pc20gZm9yIGxpbWl0aW5nIGNhbmRpZGF0ZXMgdG8gVFVSTi1vbmx5 DQoNCi0gUmVzb2x2ZWQgc2V2ZXJhbCBpbXBsZW1lbnRhdGlvbiBpc3N1ZXMNCg0KIA0KDQpJIGhh dmUgbm90IHlldCBhZGRyZXNzZWQgdGhlIG5vbi1vdmVybGFwcGluZyBjb2RlYyBjb25jZXJuIG1l bnRpb25lZCBpbiB0aGUgaW50ZXJpbSBtZWV0aW5nLiBJIHRoaW5rIHRoZXJlIGFyZSB3YXlzIG9m IGhhbmRsaW5nIHRoaXMgZWl0aGVyIGluIHRoZSBhcHBsaWNhdGlvbiBvciB0aGUgaW1wbGVtZW50 YXRpb24sIGJ1dCBJIHdhbnRlZCB0byBnZXQgdGhpcyAtMDEgb3V0IGZpcnN0IGZvciBmZWVkYmFj ay4NCg0K ------_=_NextPart_001_01CCE73F.509C59F0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDggMyA0O30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6Ik1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4 IDMgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiXEBNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAzIDQ7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywg c3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs aW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3Jh cGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJn aW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1h cmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4w cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkVtYWls U3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5IVE1MUHJlZm9y bWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJ bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRl ZCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxp c3QgbDANCgl7bXNvLWxpc3QtaWQ6MTE2NjY3Njc2MjsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsN Cgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTQ1NjQ1MTUwIDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4 NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1 O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MjcuMHB0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDoxNjc2NjkwODI0Ow0KCW1zby1s aXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxMTc2MTU0NjQ4IDYxODgx NjU1MiA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcw MyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YWxwaGEtdXBwZXI7DQoJbXNvLWxldmVsLXRleHQ6IiUxXCkiOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJn aW4tbGVmdDoyNy4wcHQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hc2NpaS1mb250LWZh bWlseTpDYWxpYnJpOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiJNUyBNaW5jaG8iOw0KCW1z by1oYW5zaS1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iO30NCkBsaXN0IGwyDQoJe21zby1saXN0LWlkOjE3NDY2MDcxNzU7DQoJbXNv LWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi01NTMzNzQzMTYgMTI1 MTc4MDkyNCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5 ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMjpsZXZlbDENCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0 OjIyLjVwdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseToiTVMgTWluY2hvIjsNCgltc28t YmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMw0KCXttc28tbGlz dC1pZDoxOTMwMDQ0NTE5Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBs YXRlLWlkczotOTE1MDg2MTM0IDYxODgxNjU1MiA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2 NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMzps ZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtdXBwZXI7DQoJbXNvLWxldmVs LXRleHQ6IiUxXCkiOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoyMi41cHQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hc2NpaS1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1mYXJlYXN0LWZvbnQt ZmFtaWx5OiJNUyBNaW5jaG8iOw0KCW1zby1oYW5zaS1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1z by1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCm9sDQoJe21hcmdpbi1ib3R0 b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1F Ti1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkp1c3Rpbiw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0LWluZGVudDo0LjVwdCc+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz5XaGF0IGhhcHBlbnMgaWYgdGhlIGFwcGxpY2F0aW9uIEphdmFT Y3JpcHQgbW9kaWZpZXMgdGhlIG9mZmVyP8KgIFRha2UgdGhlIG9mZmVyIGdlbmVyYXRpb24gaW4g ZXhhbXBsZSA3LjE6PG86cD48L286cD48L3NwYW4+PC9wPjxwcmUgc3R5bGU9J21hcmdpbi1sZWZ0 OjI3LjBwdDt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzMnPjwhW2lm ICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPjEuPHNwYW4gc3R5 bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyA8L3NwYW4+PC9zcGFuPjwh W2VuZGlmXT5PZmZlcmVySlMtJmd0O09mZmVyZXJVQTrCoMKgIHBjID0gbmV3IFBlZXJDb25uZWN0 aW9uKCk7PG86cD48L286cD48L3ByZT48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxlPSdt YXJnaW4tbGVmdDoyNy4wcHQ7dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBs Zm8zJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiQ291cmllciBOZXciJz48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz4y LjxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsgPC9zcGFu Pjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPk9mZmVyZXJKUy0mZ3Q7T2ZmZXJlclVBOsKgwqAgcGMu YWRkU3RyZWFtKGxvY2FsU3RyZWFtLCBudWxsKTs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0nbWFyZ2luLWxlZnQ6MjcuMHB0O3RleHQtaW5kZW50 Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMyc+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+PHNw YW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+My48c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGlt ZXMgTmV3IFJvbWFuIic+Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz5PZmZl cmVySlMtJmd0O09mZmVyZXJVQTrCoMKgIHBjLnN0YXJ0SWNlKCk7PG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J21hcmdpbi1sZWZ0OjI3LjBwdDt0 ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzMnPjwhW2lmICFzdXBwb3J0 TGlzdHNdPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyInPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPjQuPHNwYW4gc3R5bGU9J2ZvbnQ6 Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtl bmRpZl0+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Iic+T2ZmZXJlclVBLSZndDtPZmZlcmVySlM6wqDCoCBpY2VDYWxsYmFjayhjYW5kaWRhdGUs IGZhbHNlKTs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBz dHlsZT0nbWFyZ2luLWxlZnQ6MjcuMHB0O3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBs ZXZlbDEgbGZvMyc+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+PHNwYW4gc3R5bGU9J21zby1saXN0Okln bm9yZSc+NS48c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7 IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz5PZmZlcmVySlMtJmd0O09mZmVyZXJVQTrC oMKgIG9mZmVyID0gcGMuY3JlYXRlT2ZmZXIobnVsbCk7PG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J21hcmdpbi1sZWZ0OjI3LjBwdDt0ZXh0LWlu ZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzMnPjwhW2lmICFzdXBwb3J0TGlzdHNd PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIn PjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPjYuPHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQg IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+ T2ZmZXJlckpTLSZndDtPZmZlcmVyVUE6wqDCoCBwYy5zZXRMb2NhbERlc2NyaXB0aW9uKFNEUF9P RkZFUiwgb2ZmZXIudG9TZHAoKSk7PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb0xp c3RQYXJhZ3JhcGggc3R5bGU9J21hcmdpbi1sZWZ0OjI3LjBwdDt0ZXh0LWluZGVudDotLjI1aW47 bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzMnPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPjxzcGFuIHN0eWxl PSdtc28tbGlzdDpJZ25vcmUnPjcuPHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBS b21hbiInPiZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+T2ZmZXJlckpTLSZn dDtBbnN3ZXJlckpTOsKgIHsmcXVvdDt0eXBlJnF1b3Q7OiZxdW90O09GRkVSJnF1b3Q7LCAmcXVv dDtzZHAmcXVvdDs6JnF1b3Q7Jmx0O29mZmVyJmd0OyZxdW90O308bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDo0LjVwdCc+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtYXJnaW4tbGVmdDo0LjVwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5Db3Vs ZCB0aGUgSlMgbW9kaWZ5IHRoZSBvZmZlciBiZXR3ZWVuIHN0ZXBzIDUgYW5kIDYgb3IgYmV0d2Vl biBzdGVwcyA2IGFuZCA3P8KgIEZvciBleGFtcGxlLCBiZXR3ZWVuIHN0ZXBzIDUgYW5kIDYsIGNv dWxkIHRoZSBKUyBhZGQgYSBzdHJlYW0gZm9yIHdoaWNoIHBjLmFkZFN0cmVhbSBoYWQgbm90IGJl ZW4gY2FsbGVkIHByZXZpb3VzbHk/wqAgV291bGQgc2V0TG9jYWxEZXNjcmlwdGlvbiBtYWtlIHRo ZSBuZWNlc3NhcnkgbW9kaWZpY2F0aW9ucyBpbiB0aGF0IGNhc2U/wqAgwqDCoFdoYXQgYWJvdXQg Y2hhbmdlcyBhZnRlciBzZXRMb2NhbERlc2NyaXB0aW9uIGhhcyBiZWVuIGNhbGxlZD/CoCBBcmUg dGhleSBub3QgYWxsb3dlZD/CoCBJZiB0aGV5IGFyZSBhbGxvd2VkLCBob3cgZG9lcyB0aGUgcGVl ciBjb25uZWN0aW9uIGtub3cgd2hhdCB0byBleHBlY3QgZnJvbSB0aGUgb3RoZXIgc2lkZT/CoCA8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVm dDo0LjVwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0nbWFyZ2luLWxlZnQ6MjIuNXB0O3Rl eHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMiBsZXZlbDEgbGZvNCc+PCFbaWYgIXN1cHBvcnRM aXN0c10+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3Jl Jz4tPHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFu Pjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5KaW08bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDo0LjVwdCc+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDo0LjVwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXYgc3R5bGU9J2Jv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBp biAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiJz4gcnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpydGN3ZWItYm91bmNlc0Bp ZXRmLm9yZ10gPGI+T24gQmVoYWxmIE9mIDwvYj5KdXN0aW4gVWJlcnRpPGJyPjxiPlNlbnQ6PC9i PiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDA4LCAyMDEyIDM6NTcgUE08YnI+PGI+VG86PC9iPiBydGN3 ZWJAaWV0Zi5vcmc7IHB1YmxpYy13ZWJydGNAdzMub3JnPGJyPjxiPlN1YmplY3Q6PC9iPiBbcnRj d2ViXSBOZXcgSlNFUCBkcmFmdCBwb3N0ZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5O b3cgYXZhaWxhYmxlIGF0IDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtdWJl cnRpLXJ0Y3dlYi1qc2VwLTAxLnR4dCI+aHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC11YmVy dGktcnRjd2ViLWpzZXAtMDEudHh0PC9hPjxvOnA+PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PkluY2x1ZGVzIGNoYW5nZXMgYmFzZWQgb24gaW1wbGVtZW50YXRpb24gZmVlZGJhY2ssIGFuZCBJ IGJlbGlldmUgaXQgYWRkcmVzc2VzIG1vc3Qgb2YgdGhlIGNvbmNlcm5zIHJhaXNlZCBpbiBsYXN0 IHdlZWsncyBpbnRlcmltIG1lZXRpbmdzOjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPi0gSW5pdGlhbCBkb2N1bWVudGF0aW9uIHByb3ZpZGVkIGZvciBlYWNoIEFQ SSBjYWxsLCBhbmQgd2hhdCBzdGF0ZSBjaGFuZ2VzIGl0IGNhdXNlczxvOnA+PC9vOnA+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPi0gTW9yZSBleGFtcGxlcywgaW5jbHVkaW5nIGEg Y29tcGxldGUgYmFzaWMgc2FtcGxlIGFwcGxpY2F0aW9uPG86cD48L286cD48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+LSBTaW1wbGlmaWVkIGFwcHJvYWNoIHRvIHRyaWNrbGUgY2Fu ZGlkYXRlIGhhbmRsaW5nPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+LSBSZXNvbHZlZCBjb25jZXJucyBhYm91dCBob3cgdG8gc2VwYXJhdGUgU0RQIGF0dHJpYnV0 ZXMgaW50byBtZWRpYSAvIHRyYW5zcG9ydDxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPi0gUHJvdmlkZWQgZW5jYXBzdWxhdGlvbiBmb3IgU0RQIGJsb2JzIGFuZCBJ Q0UgY2FuZGlkYXRlIGxpbmVzLCBpbiB0aGUgZXZlbnQgd2Ugd2FudCB0byBjaGFuZ2UgZW5jb2Rp bmdzIG9yIHByb3ZpZGUgaGVscGVyIGZ1bmN0aW9ucyBmb3IgSlM8bzpwPjwvbzpwPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4tIFByb3ZpZGVkIG1lY2hhbmlzbSBmb3IgbGltaXRp bmcgY2FuZGlkYXRlcyB0byBUVVJOLW9ubHk8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD4tIFJlc29sdmVkIHNldmVyYWwgaW1wbGVtZW50YXRpb24gaXNzdWVzPG86 cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286 cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+SSBoYXZlIG5vdCB5ZXQgYWRkcmVz c2VkIHRoZSBub24tb3ZlcmxhcHBpbmcgY29kZWMgY29uY2VybiBtZW50aW9uZWQgaW4gdGhlIGlu dGVyaW0gbWVldGluZy4gSSB0aGluayB0aGVyZSBhcmUgd2F5cyBvZiBoYW5kbGluZyB0aGlzIGVp dGhlciBpbiB0aGUgYXBwbGljYXRpb24gb3IgdGhlIGltcGxlbWVudGF0aW9uLCBidXQgSSB3YW50 ZWQgdG8gZ2V0IHRoaXMgLTAxIG91dCBmaXJzdCBmb3IgZmVlZGJhY2suPG86cD48L286cD48L3A+ PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4= ------_=_NextPart_001_01CCE73F.509C59F0-- From juberti@google.com Thu Feb 9 11:39: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 B580521F86B6 for ; Thu, 9 Feb 2012 11:39:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.495 X-Spam-Level: X-Spam-Status: No, score=-101.495 tagged_above=-999 required=5 tests=[AWL=-1.079, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, RCVD_IN_BL_SPAMCOP_NET=1.96, 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 0JHHfVvAvkDY for ; Thu, 9 Feb 2012 11:39:13 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id CAA6A21F86B1 for ; Thu, 9 Feb 2012 11:39:12 -0800 (PST) Received: by iagf6 with SMTP id f6so3582663iag.31 for ; Thu, 09 Feb 2012 11:39:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=I3o5lBan+AEPD/eTuRXSPBqq2wKMthaPi407zjQnvdI=; b=BMpTBiR7NZFHYcI+YFQX25fFgtlAdB30jv1Lye8RNOB1mYokb+Xzb6LWV7aFZBbPQM ngIjP3O4bj+dBfZschz3s958kBV/L/f43Cyf/UWMLb4J7FFxN1kxpJMebna6Lv3iPXZd wSpfBMEZ757SdEViP9sOfggkGD+Zb/PpLgenE= Received: by 10.42.144.196 with SMTP id c4mr4600668icv.39.1328816352385; Thu, 09 Feb 2012 11:39:12 -0800 (PST) Received: by 10.42.144.196 with SMTP id c4mr4600657icv.39.1328816352283; Thu, 09 Feb 2012 11:39:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.85.132 with HTTP; Thu, 9 Feb 2012 11:38:52 -0800 (PST) In-Reply-To: References: From: Justin Uberti Date: Thu, 9 Feb 2012 14:38:52 -0500 Message-ID: To: Jim Barnett Content-Type: multipart/alternative; boundary=90e6ba21224ba64e2204b88d2a5a X-System-Of-Record: true X-Gm-Message-State: ALoCoQmerPQg4mqzheBX3I/VKxU9sBkKTQsyNnVL4aKEe38TyCLZHbf4+zYg7vzQ9yYMAJG+iXqfQcPRDNiNTI49urfj8H9ec4jagauHXjgJcUFQXhvRpgN0Ex0lDMCsao61xtB/lK//Sir1FGHfJLwEgcCZ/seXqA== Cc: rtcweb@ietf.org, public-webrtc@w3.org Subject: Re: [rtcweb] New JSEP draft posted 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, 09 Feb 2012 19:39:13 -0000 --90e6ba21224ba64e2204b88d2a5a Content-Type: text/plain; charset=UTF-8 On Thu, Feb 9, 2012 at 10:26 AM, Jim Barnett wrote: > Justin,**** > > What happens if the application JavaScript modifies the offer? Take the > offer generation in example 7.1:**** > > **1. **OffererJS->OffererUA: pc = new PeerConnection();**** > > **2. **OffererJS->OffererUA: pc.addStream(localStream, null);**** > > **3. **OffererJS->OffererUA: pc.startIce();**** > > **4. **OffererUA->OffererJS: iceCallback(candidate, false);**** > > **5. **OffererJS->OffererUA: offer = pc.createOffer(null);**** > > **6. **OffererJS->OffererUA: pc.setLocalDescription(SDP_OFFER, > offer.toSdp());**** > > **7. **OffererJS->AnswererJS: {"type":"OFFER", "sdp":""}**** > > ** ** > > Could the JS modify the offer between steps 5 and 6 or between steps 6 and > 7? > Yes for 5/6, but "not recommended" for 6/7. Otherwise, the UA will be out of sync with what was signaled to the remote side. > For example, between steps 5 and 6, could the JS add a stream for which > pc.addStream had not been called previously? Would setLocalDescription > make the necessary modifications in that case? > Since streams need to be coupled to actual media sources, this wouldn't work. (Or if it did, the remote side would just get a stream that never had any media). > What about changes after setLocalDescription has been called? Are > they not allowed? If they are allowed, how does the peer connection know > what to expect from the other side? > You would need to call setLocalDescription again with the modified description in order to ensure the UA is in sync with what the other side will send. > **** > > ** ** > > **- **Jim**** > > ** ** > > ** ** > > ** ** > > *From:* rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] *On > Behalf Of *Justin Uberti > *Sent:* Wednesday, February 08, 2012 3:57 PM > *To:* rtcweb@ietf.org; public-webrtc@w3.org > *Subject:* [rtcweb] New JSEP draft posted**** > > ** ** > > Now available at http://www.ietf.org/id/draft-uberti-rtcweb-jsep-01.txt*** > * > > ** ** > > Includes changes based on implementation feedback, and I believe it > addresses most of the concerns raised in last week's interim meetings:**** > > - Initial documentation provided for each API call, and what state changes > it causes**** > > - More examples, including a complete basic sample application**** > > - Simplified approach to trickle candidate handling**** > > - Resolved concerns about how to separate SDP attributes into media / > transport**** > > - Provided encapsulation for SDP blobs and ICE candidate lines, in the > event we want to change encodings or provide helper functions for JS**** > > - Provided mechanism for limiting candidates to TURN-only**** > > - Resolved several implementation issues**** > > ** ** > > I have not yet addressed the non-overlapping codec concern mentioned in > the interim meeting. I think there are ways of handling this either in the > application or the implementation, but I wanted to get this -01 out first > for feedback.**** > --90e6ba21224ba64e2204b88d2a5a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Feb 9, 2012 at 10:26 AM, Jim Bar= nett <Ji= m.Barnett@genesyslab.com> wrote:

Justin,

What happens if the application JavaScript modif= ies the offer?=C2=A0 Take the offer generation in example 7.1:

1.=C2=A0 OffererJS->Offe=
rerUA:=C2=A0=C2=A0 pc =3D new PeerConnection();

2.=C2=A0 OffererJS->OffererUA:=C2=A0=C2=A0 pc.addStream(localSt= ream, null);

3.=C2=A0 OffererJS->OffererUA:= =C2=A0=C2=A0 pc.startIce();

4.=C2=A0 OffererUA->OffererJS:= =C2=A0=C2=A0 iceCallback(candidate, false);

5.=C2=A0 OffererJS->OffererUA:= =C2=A0=C2=A0 offer =3D pc.createOffer(null);

6.=C2=A0 OffererJS->OffererUA:= =C2=A0=C2=A0 pc.setLocalDescription(SDP_OFFER, offer.toSdp());

7.=C2=A0 OffererJS->AnswererJS:= =C2=A0 {"type":"OFFER", "sdp":"<offer= >"}

=C2=A0

Could the JS modify the offer between steps 5 an= d 6 or between steps 6 and 7?


Yes for 5/6, but "not rec= ommended" for 6/7. Otherwise, the UA will be out of sync with what was= signaled to the remote side.
=C2=A0

=C2=A0 For examp= le, between steps 5 and 6, could the JS add a stream for which pc.addStream= had not been called previously?=C2=A0 Would setLocalDescription make the n= ecessary modifications in that case?


Since streams need to be coupl= ed to actual media sources, this wouldn't work. (Or if it did, the remo= te side would just get a stream that never had any media).
=C2=A0= =C2=A0

=C2=A0 =C2=A0=C2=A0What about changes after setLocalDescrip= tion has been called?=C2=A0 Are they not allowed?=C2=A0 If they are allowed= , how does the peer connection know what to expect from the other side?=C2= =A0


You would need to call setLoca= lDescription again with the modified description in order to ensure the UA = is in sync with what the other side will send.

<= /span>

=C2=A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <= /span>Jim

=C2=A0

=C2=A0

=C2=A0

From: rtcweb-bounces@ietf.o= rg [mailto:rtcweb-bounces@ietf.org] On Behalf Of Justin Uberti
Sent: Wednesday, February 08, 2012 3:57 PM
To: rtcweb@ietf.org; public-webrtc@w3.org
<= b>Subject: [rtcweb] New JSEP draft posted

=C2=A0

Now available at http://www.ietf.org/id/d= raft-uberti-rtcweb-jsep-01.txt

=C2=A0

Includes changes based on implementation feedback, and I believe= it addresses most of the concerns raised in last week's interim meetin= gs:

- Initial documentation provided for each= API call, and what state changes it causes

- More examples, including a complete basic sample appl= ication

- Simplified approach to trickle candidat= e handling

- Resolved co= ncerns about how to separate SDP attributes into media / transport

- Provided encapsulation for SDP blobs an= d ICE candidate lines, in the event we want to change encodings or provide = helper functions for JS

- Provided mechanism for limiting candidates to TURN-only

=

- Resolved several implementation issues<= u>

=C2=A0

=

I have not yet addressed the non-overlapping co= dec concern mentioned in the interim meeting. I think there are ways of han= dling this either in the application or the implementation, but I wanted to= get this -01 out first for feedback.


--90e6ba21224ba64e2204b88d2a5a-- From harald@alvestrand.no Thu Feb 9 12:29: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 6721521E8044 for ; Thu, 9 Feb 2012 12:29:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.298 X-Spam-Level: X-Spam-Status: No, score=-110.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_29=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 u4PBw-XENg67 for ; Thu, 9 Feb 2012 12:29:19 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id DC3F921F8603 for ; Thu, 9 Feb 2012 12:29:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B46B639E0E7; Thu, 9 Feb 2012 21:29:17 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ThudijZV5hPe; Thu, 9 Feb 2012 21:29:17 +0100 (CET) Received: from [10.216.248.90] (unknown [65.91.55.132]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 9186539E0BC; Thu, 9 Feb 2012 21:29:15 +0100 (CET) Message-ID: <4F342C99.50403@alvestrand.no> Date: Thu, 09 Feb 2012 12:29:13 -0800 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Jim Barnett References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------060901090307000500010406" Cc: public-webrtc@w3.org, rtcweb@ietf.org Subject: Re: [rtcweb] New JSEP draft posted 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, 09 Feb 2012 20:29:21 -0000 This is a multi-part message in MIME format. --------------060901090307000500010406 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 02/09/2012 07:26 AM, Jim Barnett wrote: > > Justin, > > What happens if the application JavaScript modifies the offer? Take > the offer generation in example 7.1: > > 1. OffererJS->OffererUA: pc = new PeerConnection(); > > 2.OffererJS->OffererUA: pc.addStream(localStream, null); > > 3.OffererJS->OffererUA: pc.startIce(); > > 4.OffererUA->OffererJS: iceCallback(candidate, false); > > 5.OffererJS->OffererUA: offer = pc.createOffer(null); > > 6.OffererJS->OffererUA: pc.setLocalDescription(SDP_OFFER, > offer.toSdp()); > > 7.OffererJS->AnswererJS: {"type":"OFFER", "sdp":""} > > Could the JS modify the offer between steps 5 and 6 or between steps 6 > and 7? For example, between steps 5 and 6, could the JS add a stream > for which pc.addStream had not been called previously? > The JS would not know what to enter for an added stream, I think. Most probably an attempt to do this should result in the SetLocalDescription being invalid, and thus rejected. Removing codecs, for instance, would be expected to cause no difficulties, and cause the right thing to happen (local UA being configured not to expect incoming data in that format). I think. > > Would setLocalDescription make the necessary modifications in that > case? What about changes after setLocalDescription has been > called? Are they not allowed? If they are allowed, how does the peer > connection know what to expect from the other side? > Seems to me that pc.setLocalDescription would have to be called again, otherwise the local PC doesn't know about the change. > > -Jim > > *From:*rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] *On > Behalf Of *Justin Uberti > *Sent:* Wednesday, February 08, 2012 3:57 PM > *To:* rtcweb@ietf.org; public-webrtc@w3.org > *Subject:* [rtcweb] New JSEP draft posted > > Now available at http://www.ietf.org/id/draft-uberti-rtcweb-jsep-01.txt > > Includes changes based on implementation feedback, and I believe it > addresses most of the concerns raised in last week's interim meetings: > > - Initial documentation provided for each API call, and what state > changes it causes > > - More examples, including a complete basic sample application > > - Simplified approach to trickle candidate handling > > - Resolved concerns about how to separate SDP attributes into media / > transport > > - Provided encapsulation for SDP blobs and ICE candidate lines, in the > event we want to change encodings or provide helper functions for JS > > - Provided mechanism for limiting candidates to TURN-only > > - Resolved several implementation issues > > I have not yet addressed the non-overlapping codec concern mentioned > in the interim meeting. I think there are ways of handling this either > in the application or the implementation, but I wanted to get this -01 > out first for feedback. > --------------060901090307000500010406 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit On 02/09/2012 07:26 AM, Jim Barnett wrote:

Justin,

What happens if the application JavaScript modifies the offer?  Take the offer generation in example 7.1:

1.  OffererJS->OffererUA:   pc = new PeerConnection();

2.  OffererJS->OffererUA:   pc.addStream(localStream, null);

3.  OffererJS->OffererUA:   pc.startIce();

4.  OffererUA->OffererJS:   iceCallback(candidate, false);

5.  OffererJS->OffererUA:   offer = pc.createOffer(null);

6.  OffererJS->OffererUA:   pc.setLocalDescription(SDP_OFFER, offer.toSdp());

7.  OffererJS->AnswererJS:  {"type":"OFFER", "sdp":"<offer>"}

 

Could the JS modify the offer between steps 5 and 6 or between steps 6 and 7?  For example, between steps 5 and 6, could the JS add a stream for which pc.addStream had not been called previously?

The JS would not know what to enter for an added stream, I think. Most probably an attempt to do this should result in the SetLocalDescription being invalid, and thus rejected.

Removing codecs, for instance, would be expected to cause no difficulties, and cause the right thing to happen (local UA being configured not to expect incoming data in that format). I think.

  Would setLocalDescription make the necessary modifications in that case?    What about changes after setLocalDescription has been called?  Are they not allowed?  If they are allowed, how does the peer connection know what to expect from the other side? 

Seems to me that pc.setLocalDescription would have to be called again, otherwise the local PC doesn't know about the change.

 

-          Jim

 

 

 

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Justin Uberti
Sent: Wednesday, February 08, 2012 3:57 PM
To: rtcweb@ietf.org; public-webrtc@w3.org
Subject: [rtcweb] New JSEP draft posted

 

Now available at http://www.ietf.org/id/draft-uberti-rtcweb-jsep-01.txt

 

Includes changes based on implementation feedback, and I believe it addresses most of the concerns raised in last week's interim meetings:

- Initial documentation provided for each API call, and what state changes it causes

- More examples, including a complete basic sample application

- Simplified approach to trickle candidate handling

- Resolved concerns about how to separate SDP attributes into media / transport

- Provided encapsulation for SDP blobs and ICE candidate lines, in the event we want to change encodings or provide helper functions for JS

- Provided mechanism for limiting candidates to TURN-only

- Resolved several implementation issues

 

I have not yet addressed the non-overlapping codec concern mentioned in the interim meeting. I think there are ways of handling this either in the application or the implementation, but I wanted to get this -01 out first for feedback.


--------------060901090307000500010406-- From Jim.Barnett@genesyslab.com Thu Feb 9 13:48: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 061CC21F8661 for ; Thu, 9 Feb 2012 13:48:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_29=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 z9+wZgF75fN3 for ; Thu, 9 Feb 2012 13:48:30 -0800 (PST) Received: from relay-out1.dc.genesyslab.com (relay-out1.dc.genesyslab.com [198.49.180.220]) by ietfa.amsl.com (Postfix) with ESMTP id 33FB721F865E for ; Thu, 9 Feb 2012 13:48:30 -0800 (PST) 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 q19LmOGB011704; Thu, 9 Feb 2012 13:48:24 -0800 (PST) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 9 Feb 2012 13:48:23 -0800 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_01CCE774.8C0CC646" Date: Thu, 9 Feb 2012 13:47:57 -0800 Message-ID: In-Reply-To: <4F342C99.50403@alvestrand.no> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] New JSEP draft posted Thread-Index: AcznaaoYZmbehUyFTUykAR8qggI/pwACQeVg References: <4F342C99.50403@alvestrand.no> From: "Jim Barnett" To: "Harald Alvestrand" X-OriginalArrivalTime: 09 Feb 2012 21:48:23.0775 (UTC) FILETIME=[8BFD2EF0:01CCE774] Cc: public-webrtc@w3.org, rtcweb@ietf.org Subject: Re: [rtcweb] New JSEP draft posted 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, 09 Feb 2012 21:48:31 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCE774.8C0CC646 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U28gd2Ugd2lsbCBuZWVkIHRvIHNwZWNpZnkgd2hpY2ggYXNwZWN0cyBvZiBhbiBvZmZlciBjYW4g YmUgbW9kaWZpZWQgYmVmb3JlIHNldExvY2FsRGVzY3JpcHRpb24gaXMgY2FsbGVkIChvciwgZXF1 aXZhbGVudGx5LCBzcGVjaWZ5IHRoZSBjb25kaXRpb25zIHVuZGVyIHdoaWNoIHNldExvY2FsRGVz Y3JpcHRpb24gbXVzdCBmYWlsKS4gICAgRm9yIGNvbXBhdGliaWxpdHkgcmVhc29ucyB3ZSB3b3Vs ZG7igJl0IHdhbnQgdG8gYWxsb3cgdGhlIGluZGl2aWR1YWwgYnJvd3NlciB2ZW5kb3JzIGRlY2lk ZSB3aGljaCBtb2RpZmljYXRpb25zIHRvIGFjY2VwdC4gIENvdWxkIHdlIGRlZmluZSBhbiBBUEkg b24gb2ZmZXIgdGhhdCB3b3VsZCBhbGxvdyBvbmx5IHRoZSBsZWdhbCBjaGFuZ2VzIHRvIGJlIG1h ZGUsIG9yIHdvdWxkIHRoYXQgYmUgaW1wcmFjdGljYWw/ICBJZiBjaGFuZ2VzIHRvIHRoZSBvZmZl ciB3ZW50IHRocm91Z2ggdGhlIEFQSSwgaXQgbWlnaHQgYmUgcG9zc2libGUgdG8gdHJhY2sgaWYg Y2hhbmdlcyBoYWQgYmVlbiBtYWRlIHNpbmNlIHRoZSBsYXN0IGNhbGwgdG8gc2V0TG9jYWxEZXNj cmlwdGlvbiwgYW5kIGF0IGxlYXN0IGlzc3VlIGEgd2FybmluZyBpZiB0aGUgYXBwbGljYXRpb24g dHJpZWQgdG8gc2VuZCBhbiBvZmZlciB0aGF0IHdhcyBvdXQgb2Ygc3luY2ggd2l0aCB0aGUgbG9j YWwgZGVzY3JpcHRpb24uICANCg0KIA0KDQpJIHN1cHBvc2UgaXTigJlzIGEgbWF0dGVyIG9mIHRh c3RlIGhvdyBtdWNoIHdlIHRyeSB0byBrZWVwIGFwcCBkZXZlbG9wZXJzIGZyb20gc2hvb3Rpbmcg dGhlbXNlbHZlcyBpbiB0aGUgZm9vdCwgIGJ1dCBpdCBzZWVtcyB0byBtZSB0aGF0IGl04oCZcyBk YW5nZXJvdXMgdG8gdGVsbCB0aGVtIHRoYXQgdGhleSBjYW4gZWRpdCB0aGUgb2ZmZXIgb2JqZWN0 IG9yIHRoZSByZXN1bHRpbmcgU0RQIHdoZW4gdGhlcmUgYXJlIHNvIG1hbnkgd2F5cyBmb3IgdGhh dCB0byBmYWlsLg0KDQogDQoNCi0gICAgICAgICAgSmltDQoNCiANCg0KRnJvbTogSGFyYWxkIEFs dmVzdHJhbmQgW21haWx0bzpoYXJhbGRAYWx2ZXN0cmFuZC5ub10gDQpTZW50OiBUaHVyc2RheSwg RmVicnVhcnkgMDksIDIwMTIgMzoyOSBQTQ0KVG86IEppbSBCYXJuZXR0DQpDYzogSnVzdGluIFVi ZXJ0aTsgcnRjd2ViQGlldGYub3JnOyBwdWJsaWMtd2VicnRjQHczLm9yZw0KU3ViamVjdDogUmU6 IFtydGN3ZWJdIE5ldyBKU0VQIGRyYWZ0IHBvc3RlZA0KDQogDQoNCk9uIDAyLzA5LzIwMTIgMDc6 MjYgQU0sIEppbSBCYXJuZXR0IHdyb3RlOiANCg0KSnVzdGluLA0KDQpXaGF0IGhhcHBlbnMgaWYg dGhlIGFwcGxpY2F0aW9uIEphdmFTY3JpcHQgbW9kaWZpZXMgdGhlIG9mZmVyPyAgVGFrZSB0aGUg b2ZmZXIgZ2VuZXJhdGlvbiBpbiBleGFtcGxlIDcuMToNCg0KT2ZmZXJlckpTLT5PZmZlcmVyVUE6 ICAgcGMgPSBuZXcgUGVlckNvbm5lY3Rpb24oKTsNCg0KT2ZmZXJlckpTLT5PZmZlcmVyVUE6ICAg cGMuYWRkU3RyZWFtKGxvY2FsU3RyZWFtLCBudWxsKTsNCg0KT2ZmZXJlckpTLT5PZmZlcmVyVUE6 ICAgcGMuc3RhcnRJY2UoKTsNCg0KT2ZmZXJlclVBLT5PZmZlcmVySlM6ICAgaWNlQ2FsbGJhY2so Y2FuZGlkYXRlLCBmYWxzZSk7DQoNCk9mZmVyZXJKUy0+T2ZmZXJlclVBOiAgIG9mZmVyID0gcGMu Y3JlYXRlT2ZmZXIobnVsbCk7DQoNCk9mZmVyZXJKUy0+T2ZmZXJlclVBOiAgIHBjLnNldExvY2Fs RGVzY3JpcHRpb24oU0RQX09GRkVSLCBvZmZlci50b1NkcCgpKTsNCg0KT2ZmZXJlckpTLT5BbnN3 ZXJlckpTOiAgeyJ0eXBlIjoiT0ZGRVIiLCAic2RwIjoiPG9mZmVyPiJ9DQoNCiANCg0KQ291bGQg dGhlIEpTIG1vZGlmeSB0aGUgb2ZmZXIgYmV0d2VlbiBzdGVwcyA1IGFuZCA2IG9yIGJldHdlZW4g c3RlcHMgNiBhbmQgNz8gIEZvciBleGFtcGxlLCBiZXR3ZWVuIHN0ZXBzIDUgYW5kIDYsIGNvdWxk IHRoZSBKUyBhZGQgYSBzdHJlYW0gZm9yIHdoaWNoIHBjLmFkZFN0cmVhbSBoYWQgbm90IGJlZW4g Y2FsbGVkIHByZXZpb3VzbHk/DQoNClRoZSBKUyB3b3VsZCBub3Qga25vdyB3aGF0IHRvIGVudGVy IGZvciBhbiBhZGRlZCBzdHJlYW0sIEkgdGhpbmsuIE1vc3QgcHJvYmFibHkgYW4gYXR0ZW1wdCB0 byBkbyB0aGlzIHNob3VsZCByZXN1bHQgaW4gdGhlIFNldExvY2FsRGVzY3JpcHRpb24gYmVpbmcg aW52YWxpZCwgYW5kIHRodXMgcmVqZWN0ZWQuDQoNClJlbW92aW5nIGNvZGVjcywgZm9yIGluc3Rh bmNlLCB3b3VsZCBiZSBleHBlY3RlZCB0byBjYXVzZSBubyBkaWZmaWN1bHRpZXMsIGFuZCBjYXVz ZSB0aGUgcmlnaHQgdGhpbmcgdG8gaGFwcGVuIChsb2NhbCBVQSBiZWluZyBjb25maWd1cmVkIG5v dCB0byBleHBlY3QgaW5jb21pbmcgZGF0YSBpbiB0aGF0IGZvcm1hdCkuIEkgdGhpbmsuDQoNCg0K DQogIFdvdWxkIHNldExvY2FsRGVzY3JpcHRpb24gbWFrZSB0aGUgbmVjZXNzYXJ5IG1vZGlmaWNh dGlvbnMgaW4gdGhhdCBjYXNlPyAgICBXaGF0IGFib3V0IGNoYW5nZXMgYWZ0ZXIgc2V0TG9jYWxE ZXNjcmlwdGlvbiBoYXMgYmVlbiBjYWxsZWQ/ICBBcmUgdGhleSBub3QgYWxsb3dlZD8gIElmIHRo ZXkgYXJlIGFsbG93ZWQsIGhvdyBkb2VzIHRoZSBwZWVyIGNvbm5lY3Rpb24ga25vdyB3aGF0IHRv IGV4cGVjdCBmcm9tIHRoZSBvdGhlciBzaWRlPyAgDQoNClNlZW1zIHRvIG1lIHRoYXQgcGMuc2V0 TG9jYWxEZXNjcmlwdGlvbiB3b3VsZCBoYXZlIHRvIGJlIGNhbGxlZCBhZ2Fpbiwgb3RoZXJ3aXNl IHRoZSBsb2NhbCBQQyBkb2Vzbid0IGtub3cgYWJvdXQgdGhlIGNoYW5nZS4NCg0KDQoNCiANCg0K SmltDQoNCiANCg0KIA0KDQogDQoNCkZyb206IHJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnIFttYWls dG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKdXN0aW4gVWJlcnRpDQpT ZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDA4LCAyMDEyIDM6NTcgUE0NClRvOiBydGN3ZWJAaWV0 Zi5vcmc7IHB1YmxpYy13ZWJydGNAdzMub3JnDQpTdWJqZWN0OiBbcnRjd2ViXSBOZXcgSlNFUCBk cmFmdCBwb3N0ZWQNCg0KIA0KDQpOb3cgYXZhaWxhYmxlIGF0IGh0dHA6Ly93d3cuaWV0Zi5vcmcv aWQvZHJhZnQtdWJlcnRpLXJ0Y3dlYi1qc2VwLTAxLnR4dA0KDQogDQoNCkluY2x1ZGVzIGNoYW5n ZXMgYmFzZWQgb24gaW1wbGVtZW50YXRpb24gZmVlZGJhY2ssIGFuZCBJIGJlbGlldmUgaXQgYWRk cmVzc2VzIG1vc3Qgb2YgdGhlIGNvbmNlcm5zIHJhaXNlZCBpbiBsYXN0IHdlZWsncyBpbnRlcmlt IG1lZXRpbmdzOg0KDQotIEluaXRpYWwgZG9jdW1lbnRhdGlvbiBwcm92aWRlZCBmb3IgZWFjaCBB UEkgY2FsbCwgYW5kIHdoYXQgc3RhdGUgY2hhbmdlcyBpdCBjYXVzZXMNCg0KLSBNb3JlIGV4YW1w bGVzLCBpbmNsdWRpbmcgYSBjb21wbGV0ZSBiYXNpYyBzYW1wbGUgYXBwbGljYXRpb24NCg0KLSBT aW1wbGlmaWVkIGFwcHJvYWNoIHRvIHRyaWNrbGUgY2FuZGlkYXRlIGhhbmRsaW5nDQoNCi0gUmVz b2x2ZWQgY29uY2VybnMgYWJvdXQgaG93IHRvIHNlcGFyYXRlIFNEUCBhdHRyaWJ1dGVzIGludG8g bWVkaWEgLyB0cmFuc3BvcnQNCg0KLSBQcm92aWRlZCBlbmNhcHN1bGF0aW9uIGZvciBTRFAgYmxv YnMgYW5kIElDRSBjYW5kaWRhdGUgbGluZXMsIGluIHRoZSBldmVudCB3ZSB3YW50IHRvIGNoYW5n ZSBlbmNvZGluZ3Mgb3IgcHJvdmlkZSBoZWxwZXIgZnVuY3Rpb25zIGZvciBKUw0KDQotIFByb3Zp ZGVkIG1lY2hhbmlzbSBmb3IgbGltaXRpbmcgY2FuZGlkYXRlcyB0byBUVVJOLW9ubHkNCg0KLSBS ZXNvbHZlZCBzZXZlcmFsIGltcGxlbWVudGF0aW9uIGlzc3Vlcw0KDQogDQoNCkkgaGF2ZSBub3Qg eWV0IGFkZHJlc3NlZCB0aGUgbm9uLW92ZXJsYXBwaW5nIGNvZGVjIGNvbmNlcm4gbWVudGlvbmVk IGluIHRoZSBpbnRlcmltIG1lZXRpbmcuIEkgdGhpbmsgdGhlcmUgYXJlIHdheXMgb2YgaGFuZGxp bmcgdGhpcyBlaXRoZXIgaW4gdGhlIGFwcGxpY2F0aW9uIG9yIHRoZSBpbXBsZW1lbnRhdGlvbiwg YnV0IEkgd2FudGVkIHRvIGdldCB0aGlzIC0wMSBvdXQgZmlyc3QgZm9yIGZlZWRiYWNrLg0KDQog DQoNCg== ------_=_NextPart_001_01CCE774.8C0CC646 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDggMyA0O30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6Ik1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4 IDMgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiXEBNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAzIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseToiQ291cmllciBOZXcgXDsiOw0KCXBhbm9zZS0xOjAgMCAwIDAg MCAwIDAgMCAwIDA7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU TUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglj b2xvcjpibGFjazt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRl DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0 IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6Ymxh Y2s7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlz dFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJ bWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5IVE1M UHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hh ciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZv cm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkVtYWlsU3R5bGUy MA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHls ZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjpibGFjazt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRp b25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo5MjQ4NDgwNTk7DQoJbXNvLWxpc3QtdHlw ZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjEwNjgzMDA4NzAgMTEzNjE1NjU5MiA2 NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5 ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWZvbnQt ZmFtaWx5OiJNUyBNaW5jaG8iOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGlu O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT48L2hlYWQ+PGJvZHkgYmdjb2xvcj13aGl0ZSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGlu az1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+U28gd2Ugd2lsbCBuZWVkIHRvIHNwZWNpZnkgd2hpY2ggYXNwZWN0 cyBvZiBhbiBvZmZlciBjYW4gYmUgbW9kaWZpZWQgYmVmb3JlIHNldExvY2FsRGVzY3JpcHRpb24g aXMgY2FsbGVkIChvciwgZXF1aXZhbGVudGx5LCBzcGVjaWZ5IHRoZSBjb25kaXRpb25zIHVuZGVy IHdoaWNoIHNldExvY2FsRGVzY3JpcHRpb24gbXVzdCBmYWlsKS4gwqDCoMKgRm9yIGNvbXBhdGli aWxpdHkgcmVhc29ucyB3ZSB3b3VsZG7igJl0IHdhbnQgdG8gYWxsb3cgdGhlIGluZGl2aWR1YWwg YnJvd3NlciB2ZW5kb3JzIGRlY2lkZSB3aGljaCBtb2RpZmljYXRpb25zIHRvIGFjY2VwdC7CoCBD b3VsZCB3ZSBkZWZpbmUgYW4gQVBJIG9uIG9mZmVyIHRoYXQgd291bGQgYWxsb3cgb25seSB0aGUg bGVnYWwgY2hhbmdlcyB0byBiZSBtYWRlLCBvciB3b3VsZCB0aGF0IGJlIGltcHJhY3RpY2FsP8Kg IElmIGNoYW5nZXMgdG8gdGhlIG9mZmVyIHdlbnQgdGhyb3VnaCB0aGUgQVBJLCBpdCBtaWdodCBi ZSBwb3NzaWJsZSB0byB0cmFjayBpZiBjaGFuZ2VzIGhhZCBiZWVuIG1hZGUgc2luY2UgdGhlIGxh c3QgY2FsbCB0byBzZXRMb2NhbERlc2NyaXB0aW9uLCBhbmQgYXQgbGVhc3QgaXNzdWUgYSB3YXJu aW5nIGlmIHRoZSBhcHBsaWNhdGlvbiB0cmllZCB0byBzZW5kIGFuIG9mZmVyIHRoYXQgd2FzIG91 dCBvZiBzeW5jaCB3aXRoIHRoZSBsb2NhbCBkZXNjcmlwdGlvbi7CoCA8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5 N0QnPkkgc3VwcG9zZSBpdOKAmXMgYSBtYXR0ZXIgb2YgdGFzdGUgaG93IG11Y2ggd2UgdHJ5IHRv IGtlZXAgYXBwIGRldmVsb3BlcnMgZnJvbSBzaG9vdGluZyB0aGVtc2VsdmVzIGluIHRoZSBmb290 LMKgIGJ1dCBpdCBzZWVtcyB0byBtZSB0aGF0IGl04oCZcyBkYW5nZXJvdXMgdG8gdGVsbCB0aGVt IHRoYXQgdGhleSBjYW4gZWRpdCB0aGUgb2ZmZXIgb2JqZWN0IG9yIHRoZSByZXN1bHRpbmcgU0RQ IHdoZW4gdGhlcmUgYXJlIHNvIG1hbnkgd2F5cyBmb3IgdGhhdCB0byBmYWlsLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0n dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xJz48IVtpZiAhc3VwcG9y dExpc3RzXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25v cmUnPi08c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3Nw YW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkppbTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+PHAg Y2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjtjb2xvcjp3aW5kb3d0ZXh0Jz5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNh bnMtc2VyaWYiO2NvbG9yOndpbmRvd3RleHQnPiBIYXJhbGQgQWx2ZXN0cmFuZCBbbWFpbHRvOmhh cmFsZEBhbHZlc3RyYW5kLm5vXSA8YnI+PGI+U2VudDo8L2I+IFRodXJzZGF5LCBGZWJydWFyeSAw OSwgMjAxMiAzOjI5IFBNPGJyPjxiPlRvOjwvYj4gSmltIEJhcm5ldHQ8YnI+PGI+Q2M6PC9iPiBK dXN0aW4gVWJlcnRpOyBydGN3ZWJAaWV0Zi5vcmc7IHB1YmxpYy13ZWJydGNAdzMub3JnPGJyPjxi PlN1YmplY3Q6PC9iPiBSZTogW3J0Y3dlYl0gTmV3IEpTRVAgZHJhZnQgcG9zdGVkPG86cD48L286 cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwv bzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+T24gMDIvMDkvMjAxMiAwNzoyNiBBTSwgSmltIEJh cm5ldHQgd3JvdGU6IDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz5K dXN0aW4sPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0ndGV4 dC1pbmRlbnQ6NC41cHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPldoYXQgaGFwcGVucyBpZiB0aGUgYXBwbGljYXRpb24g SmF2YVNjcmlwdCBtb2RpZmllcyB0aGUgb2ZmZXI/Jm5ic3A7IFRha2UgdGhlIG9mZmVyIGdlbmVy YXRpb24gaW4gZXhhbXBsZSA3LjE6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwcmUgc3R5bGU9J21h cmdpbi1sZWZ0OjI3LjBwdDt0ZXh0LWluZGVudDotLjI1aW4nPk9mZmVyZXJKUy0mZ3Q7T2ZmZXJl clVBOiZuYnNwOyZuYnNwOyBwYyA9IG5ldyBQZWVyQ29ubmVjdGlvbigpOzxvOnA+PC9vOnA+PC9w cmU+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0nbWFyZ2luLWxlZnQ6MjcuMHB0O3Rl eHQtaW5kZW50Oi0uMjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3IDsiLCJzZXJpZiInPk9mZmVyZXJKUy0mZ3Q7T2ZmZXJlclVBOiZuYnNw OyZuYnNwOyBwYy5hZGRTdHJlYW0obG9jYWxTdHJlYW0sIG51bGwpOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxlPSdtYXJnaW4tbGVmdDoyNy4wcHQ7 dGV4dC1pbmRlbnQ6LS4yNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiQ291cmllciBOZXcgOyIsInNlcmlmIic+T2ZmZXJlckpTLSZndDtPZmZlcmVyVUE6Jm5i c3A7Jm5ic3A7IHBjLnN0YXJ0SWNlKCk7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1z b0xpc3RQYXJhZ3JhcGggc3R5bGU9J21hcmdpbi1sZWZ0OjI3LjBwdDt0ZXh0LWluZGVudDotLjI1 aW4nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyA7Iiwic2VyaWYiJz5PZmZlcmVyVUEtJmd0O09mZmVyZXJKUzombmJzcDsmbmJzcDsgaWNlQ2Fs bGJhY2soY2FuZGlkYXRlLCBmYWxzZSk7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1z b0xpc3RQYXJhZ3JhcGggc3R5bGU9J21hcmdpbi1sZWZ0OjI3LjBwdDt0ZXh0LWluZGVudDotLjI1 aW4nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyA7Iiwic2VyaWYiJz5PZmZlcmVySlMtJmd0O09mZmVyZXJVQTombmJzcDsmbmJzcDsgb2ZmZXIg PSBwYy5jcmVhdGVPZmZlcihudWxsKTs8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNv TGlzdFBhcmFncmFwaCBzdHlsZT0nbWFyZ2luLWxlZnQ6MjcuMHB0O3RleHQtaW5kZW50Oi0uMjVp bic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 IDsiLCJzZXJpZiInPk9mZmVyZXJKUy0mZ3Q7T2ZmZXJlclVBOiZuYnNwOyZuYnNwOyBwYy5zZXRM b2NhbERlc2NyaXB0aW9uKFNEUF9PRkZFUiwgb2ZmZXIudG9TZHAoKSk7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J21hcmdpbi1sZWZ0OjI3LjBw dDt0ZXh0LWluZGVudDotLjI1aW4nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyA7Iiwic2VyaWYiJz5PZmZlcmVySlMtJmd0O0Fuc3dlcmVySlM6 Jm5ic3A7IHsmcXVvdDt0eXBlJnF1b3Q7OiZxdW90O09GRkVSJnF1b3Q7LCAmcXVvdDtzZHAmcXVv dDs6JnF1b3Q7Jmx0O29mZmVyJmd0OyZxdW90O308L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDo0LjVwdCc+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6 NC41cHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiInPkNvdWxkIHRoZSBKUyBtb2RpZnkgdGhlIG9mZmVyIGJldHdlZW4gc3Rl cHMgNSBhbmQgNiBvciBiZXR3ZWVuIHN0ZXBzIDYgYW5kIDc/Jm5ic3A7IEZvciBleGFtcGxlLCBi ZXR3ZWVuIHN0ZXBzIDUgYW5kIDYsIGNvdWxkIHRoZSBKUyBhZGQgYSBzdHJlYW0gZm9yIHdoaWNo IHBjLmFkZFN0cmVhbSBoYWQgbm90IGJlZW4gY2FsbGVkIHByZXZpb3VzbHk/PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5UaGUgSlMgd291bGQgbm90IGtub3cgd2hhdCB0 byBlbnRlciBmb3IgYW4gYWRkZWQgc3RyZWFtLCBJIHRoaW5rLiBNb3N0IHByb2JhYmx5IGFuIGF0 dGVtcHQgdG8gZG8gdGhpcyBzaG91bGQgcmVzdWx0IGluIHRoZSBTZXRMb2NhbERlc2NyaXB0aW9u IGJlaW5nIGludmFsaWQsIGFuZCB0aHVzIHJlamVjdGVkLjxicj48YnI+UmVtb3ZpbmcgY29kZWNz LCBmb3IgaW5zdGFuY2UsIHdvdWxkIGJlIGV4cGVjdGVkIHRvIGNhdXNlIG5vIGRpZmZpY3VsdGll cywgYW5kIGNhdXNlIHRoZSByaWdodCB0aGluZyB0byBoYXBwZW4gKGxvY2FsIFVBIGJlaW5nIGNv bmZpZ3VyZWQgbm90IHRvIGV4cGVjdCBpbmNvbWluZyBkYXRhIGluIHRoYXQgZm9ybWF0KS4gSSB0 aGluay48YnI+PGJyPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFy Z2luLWxlZnQ6NC41cHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPiZuYnNwOyBXb3VsZCBzZXRMb2NhbERlc2NyaXB0aW9u IG1ha2UgdGhlIG5lY2Vzc2FyeSBtb2RpZmljYXRpb25zIGluIHRoYXQgY2FzZT8mbmJzcDsgJm5i c3A7Jm5ic3A7V2hhdCBhYm91dCBjaGFuZ2VzIGFmdGVyIHNldExvY2FsRGVzY3JpcHRpb24gaGFz IGJlZW4gY2FsbGVkPyZuYnNwOyBBcmUgdGhleSBub3QgYWxsb3dlZD8mbmJzcDsgSWYgdGhleSBh cmUgYWxsb3dlZCwgaG93IGRvZXMgdGhlIHBlZXIgY29ubmVjdGlvbiBrbm93IHdoYXQgdG8gZXhw ZWN0IGZyb20gdGhlIG90aGVyIHNpZGU/Jm5ic3A7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+U2VlbXMgdG8gbWUgdGhhdCBwYy5zZXRMb2NhbERlc2NyaXB0aW9uIHdv dWxkIGhhdmUgdG8gYmUgY2FsbGVkIGFnYWluLCBvdGhlcndpc2UgdGhlIGxvY2FsIFBDIGRvZXNu J3Qga25vdyBhYm91dCB0aGUgY2hhbmdlLjxicj48YnI+PG86cD48L286cD48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDo0LjVwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J21hcmdpbi1s ZWZ0OjIyLjVwdDt0ZXh0LWluZGVudDotLjI1aW4nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPkppbTwvc3Bhbj48bzpwPjwv bzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0OjQuNXB0Jz48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiJz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtYXJnaW4tbGVmdDo0LjVwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW47Ym9yZGVyLWNvbG9yOnJnYigxODEsJiMxMzsmIzEw OyAgICAgICAgICAxOTYsIDIyMykgLW1vei11c2UtdGV4dC1jb2xvciAtbW96LXVzZS10ZXh0LWNv bG9yJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYi Jz4gPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnIj5ydGN3ZWItYm91bmNl c0BpZXRmLm9yZzwvYT4gWzxhIGhyZWY9Im1haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZyI+ bWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnPC9hPl0gPGI+T24gQmVoYWxmIE9mIDwvYj5K dXN0aW4gVWJlcnRpPGJyPjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDA4LCAyMDEy IDM6NTcgUE08YnI+PGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIj5y dGN3ZWJAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86cHVibGljLXdlYnJ0Y0B3My5vcmci PnB1YmxpYy13ZWJydGNAdzMub3JnPC9hPjxicj48Yj5TdWJqZWN0OjwvYj4gW3J0Y3dlYl0gTmV3 IEpTRVAgZHJhZnQgcG9zdGVkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNzPU1z b05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+Tm93IGF2YWls YWJsZSBhdCA8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LXViZXJ0aS1ydGN3 ZWItanNlcC0wMS50eHQiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtdWJlcnRpLXJ0Y3dl Yi1qc2VwLTAxLnR4dDwvYT48bzpwPjwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4m bmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5JbmNsdWRl cyBjaGFuZ2VzIGJhc2VkIG9uIGltcGxlbWVudGF0aW9uIGZlZWRiYWNrLCBhbmQgSSBiZWxpZXZl IGl0IGFkZHJlc3NlcyBtb3N0IG9mIHRoZSBjb25jZXJucyByYWlzZWQgaW4gbGFzdCB3ZWVrJ3Mg aW50ZXJpbSBtZWV0aW5nczo8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD4tIEluaXRpYWwgZG9jdW1lbnRhdGlvbiBwcm92aWRlZCBmb3IgZWFjaCBBUEkgY2FsbCwg YW5kIHdoYXQgc3RhdGUgY2hhbmdlcyBpdCBjYXVzZXM8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD4tIE1vcmUgZXhhbXBsZXMsIGluY2x1ZGluZyBhIGNvbXBsZXRl IGJhc2ljIHNhbXBsZSBhcHBsaWNhdGlvbjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPi0gU2ltcGxpZmllZCBhcHByb2FjaCB0byB0cmlja2xlIGNhbmRpZGF0ZSBo YW5kbGluZzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPi0gUmVz b2x2ZWQgY29uY2VybnMgYWJvdXQgaG93IHRvIHNlcGFyYXRlIFNEUCBhdHRyaWJ1dGVzIGludG8g bWVkaWEgLyB0cmFuc3BvcnQ8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD4tIFByb3ZpZGVkIGVuY2Fwc3VsYXRpb24gZm9yIFNEUCBibG9icyBhbmQgSUNFIGNhbmRp ZGF0ZSBsaW5lcywgaW4gdGhlIGV2ZW50IHdlIHdhbnQgdG8gY2hhbmdlIGVuY29kaW5ncyBvciBw cm92aWRlIGhlbHBlciBmdW5jdGlvbnMgZm9yIEpTPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+LSBQcm92aWRlZCBtZWNoYW5pc20gZm9yIGxpbWl0aW5nIGNhbmRp ZGF0ZXMgdG8gVFVSTi1vbmx5PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+LSBSZXNvbHZlZCBzZXZlcmFsIGltcGxlbWVudGF0aW9uIGlzc3VlczxvOnA+PC9vOnA+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkkgaGF2ZSBub3QgeWV0IGFkZHJlc3NlZCB0aGUg bm9uLW92ZXJsYXBwaW5nIGNvZGVjIGNvbmNlcm4gbWVudGlvbmVkIGluIHRoZSBpbnRlcmltIG1l ZXRpbmcuIEkgdGhpbmsgdGhlcmUgYXJlIHdheXMgb2YgaGFuZGxpbmcgdGhpcyBlaXRoZXIgaW4g dGhlIGFwcGxpY2F0aW9uIG9yIHRoZSBpbXBsZW1lbnRhdGlvbiwgYnV0IEkgd2FudGVkIHRvIGdl dCB0aGlzIC0wMSBvdXQgZmlyc3QgZm9yIGZlZWRiYWNrLjxvOnA+PC9vOnA+PC9wPjwvZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48L2JvZHk+PC9odG1s Pg== ------_=_NextPart_001_01CCE774.8C0CC646-- From juberti@google.com Thu Feb 9 13:52: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 33AA721F8699 for ; Thu, 9 Feb 2012 13:52:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.454 X-Spam-Level: X-Spam-Status: No, score=-101.454 tagged_above=-999 required=5 tests=[AWL=-1.038, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, RCVD_IN_BL_SPAMCOP_NET=1.96, 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 01XsQLyFbHFl for ; Thu, 9 Feb 2012 13:52:29 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0F06C21F8697 for ; Thu, 9 Feb 2012 13:52:28 -0800 (PST) Received: by iagf6 with SMTP id f6so3771534iag.31 for ; Thu, 09 Feb 2012 13:52:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=xO9JYMf8w2a9NU5v8PCkPV5hbFyg+2A8cROmD9OZy20=; b=Yadhx31/wZWTweTTTZlTDkZVwNLM3FK49k+oj12hVaLI2Zr27JRcNan8lU7HnVaid8 gplKzr0W19HaO9cHVmLabVIwywcXdee0YntWQzpvmSWGJKgHiuhUhy94yOB4P9HhiaX2 gIwKxCp3t3UPKbYqhJryZosqOUw5VFEj9PQaU= Received: by 10.42.235.137 with SMTP id kg9mr5199189icb.47.1328824348668; Thu, 09 Feb 2012 13:52:28 -0800 (PST) Received: by 10.42.235.137 with SMTP id kg9mr5199065icb.47.1328824346342; Thu, 09 Feb 2012 13:52:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.85.132 with HTTP; Thu, 9 Feb 2012 13:52:06 -0800 (PST) In-Reply-To: References: <4F342C99.50403@alvestrand.no> From: Justin Uberti Date: Thu, 9 Feb 2012 16:52:06 -0500 Message-ID: To: Jim Barnett Content-Type: multipart/alternative; boundary=20cf3026697a21f5e204b88f0781 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlA1lAvt2Lx0l6lXYl92rmjgnHQHMwNTwF7LjiYAwyodhqyCc+wKITTIhausc11pArdIALeBsFGuC2xx1NhZYy6aRYye5xBzbL4f41CLJI6e4lyZkF38Z2Lg+6SiG5i460Q52YLQUN6YzAImZ1w3ZiPK4+PCw== Cc: rtcweb@ietf.org, public-webrtc@w3.org Subject: Re: [rtcweb] New JSEP draft posted 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, 09 Feb 2012 21:52:30 -0000 --20cf3026697a21f5e204b88f0781 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree we should provide guidance here on what can be changed, and fail any edits that are disallowed. We can do this while nailing down exactly what parts of SDP all implementations must support. On Thu, Feb 9, 2012 at 4:47 PM, Jim Barnett wro= te: > So we will need to specify which aspects of an offer can be modified > before setLocalDescription is called (or, equivalently, specify the > conditions under which setLocalDescription must fail). For compatibili= ty > reasons we wouldn=E2=80=99t want to allow the individual browser vendors = decide > which modifications to accept. Could we define an API on offer that woul= d > allow only the legal changes to be made, or would that be impractical? I= f > changes to the offer went through the API, it might be possible to track = if > changes had been made since the last call to setLocalDescription, and at > least issue a warning if the application tried to send an offer that was > out of synch with the local description. **** > > ** ** > > I suppose it=E2=80=99s a matter of taste how much we try to keep app deve= lopers > from shooting themselves in the foot, but it seems to me that it=E2=80= =99s > dangerous to tell them that they can edit the offer object or the resulti= ng > SDP when there are so many ways for that to fail.**** > > ** ** > > **- **Jim**** > > ** ** > > *From:* Harald Alvestrand [mailto:harald@alvestrand.no] > *Sent:* Thursday, February 09, 2012 3:29 PM > *To:* Jim Barnett > *Cc:* Justin Uberti; rtcweb@ietf.org; public-webrtc@w3.org > *Subject:* Re: [rtcweb] New JSEP draft posted**** > > ** ** > > On 02/09/2012 07:26 AM, Jim Barnett wrote: **** > > Justin,**** > > What happens if the application JavaScript modifies the offer? Take the > offer generation in example 7.1:**** > > OffererJS->OffererUA: pc =3D new PeerConnection();**** > > OffererJS->OffererUA: pc.addStream(localStream, null);**** > > OffererJS->OffererUA: pc.startIce();**** > > OffererUA->OffererJS: iceCallback(candidate, false);**** > > OffererJS->OffererUA: offer =3D pc.createOffer(null);**** > > OffererJS->OffererUA: pc.setLocalDescription(SDP_OFFER, offer.toSdp());= * > *** > > OffererJS->AnswererJS: {"type":"OFFER", "sdp":""}**** > > **** > > Could the JS modify the offer between steps 5 and 6 or between steps 6 an= d > 7? For example, between steps 5 and 6, could the JS add a stream for whi= ch > pc.addStream had not been called previously?**** > > The JS would not know what to enter for an added stream, I think. Most > probably an attempt to do this should result in the SetLocalDescription > being invalid, and thus rejected. > > Removing codecs, for instance, would be expected to cause no difficulties= , > and cause the right thing to happen (local UA being configured not to > expect incoming data in that format). I think. > > **** > > Would setLocalDescription make the necessary modifications in that > case? What about changes after setLocalDescription has been called? A= re > they not allowed? If they are allowed, how does the peer connection know > what to expect from the other side? **** > > Seems to me that pc.setLocalDescription would have to be called again, > otherwise the local PC doesn't know about the change. > > **** > > **** > > Jim**** > > **** > > **** > > **** > > *From:* rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] > *On Behalf Of *Justin Uberti > *Sent:* Wednesday, February 08, 2012 3:57 PM > *To:* rtcweb@ietf.org; public-webrtc@w3.org > *Subject:* [rtcweb] New JSEP draft posted**** > > **** > > Now available at http://www.ietf.org/id/draft-uberti-rtcweb-jsep-01.txt**= * > * > > **** > > Includes changes based on implementation feedback, and I believe it > addresses most of the concerns raised in last week's interim meetings:***= * > > - Initial documentation provided for each API call, and what state change= s > it causes**** > > - More examples, including a complete basic sample application**** > > - Simplified approach to trickle candidate handling**** > > - Resolved concerns about how to separate SDP attributes into media / > transport**** > > - Provided encapsulation for SDP blobs and ICE candidate lines, in the > event we want to change encodings or provide helper functions for JS**** > > - Provided mechanism for limiting candidates to TURN-only**** > > - Resolved several implementation issues**** > > **** > > I have not yet addressed the non-overlapping codec concern mentioned in > the interim meeting. I think there are ways of handling this either in th= e > application or the implementation, but I wanted to get this -01 out first > for feedback.**** > > ** ** > --20cf3026697a21f5e204b88f0781 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree we should provide guidance here on what can be changed, and fail an= y edits that are disallowed. We can do this while nailing down exactly what= parts of SDP all implementations must support.

On Thu, Feb 9, 2012 at 4:47 PM, Jim Barnett <Jim.Barnett@genesyslab.com> wrote:
<= p class=3D"MsoNormal">So we will need to specify= which aspects of an offer can be modified before setLocalDescription is ca= lled (or, equivalently, specify the conditions under which setLocalDescript= ion must fail). =C2=A0=C2=A0=C2=A0For compatibility reasons we wouldn=E2=80= =99t want to allow the individual browser vendors decide which modification= s to accept.=C2=A0 Could we define an API on offer that would allow only th= e legal changes to be made, or would that be impractical?=C2=A0 If changes = to the offer went through the API, it might be possible to track if changes= had been made since the last call to setLocalDescription, and at least iss= ue a warning if the application tried to send an offer that was out of sync= h with the local description.=C2=A0

=C2=A0

I suppose it=E2=80= =99s a matter of taste how much we try to keep app developers from shooting= themselves in the foot,=C2=A0 but it seems to me that it=E2=80=99s dangero= us to tell them that they can edit the offer object or the resulting SDP wh= en there are so many ways for that to fail.

=C2=A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Jim=

=C2=A0

From: Harald Alvestrand [mailto:harald@alvestrand.no]
Sent: Thursday, February 09, 2012 3:29 PM
To: Jim Barnett<= br>Cc: Justin Uberti; rtcweb@ietf.org; public-webrtc@w3.org
Subject: Re: [rtcweb] New JSEP draft posted

=

=C2=A0

On 02/09/2012 07:26 AM, Jim Barnett wrote: =

Justin,

What happens if th= e application JavaScript modifies the offer?=C2=A0 Take the offer generatio= n in example 7.1:

OffererJS->OffererUA:=C2=A0=C2=
=A0 pc =3D new PeerConnection();

OffererJS->OffererUA:=C2=A0=C2=A0 pc.addStream(lo= calStream, null);

OffererJS->OffererUA:=C2= =A0=C2=A0 pc.startIce();

OffererUA->OffererJS:=C2=A0=C2=A0 iceCallback(candid= ate, false);

OffererJS-&= gt;OffererUA:=C2=A0=C2=A0 offer =3D pc.createOffer(null);<= /u>

OffererJS->OffererUA:=C2=A0=C2=A0 pc.setLocalDescription(S= DP_OFFER, offer.toSdp());

OffererJS->AnswererJS:=C2=A0 {"type":"OFFER= ", "sdp":"<offer>"}

=

=C2=A0

Could the JS modify the offer between step= s 5 and 6 or between steps 6 and 7?=C2=A0 For example, between steps 5 and = 6, could the JS add a stream for which pc.addStream had not been called pre= viously?

The JS would not know what to enter for an added str= eam, I think. Most probably an attempt to do this should result in the SetL= ocalDescription being invalid, and thus rejected.

Removing codecs, f= or instance, would be expected to cause no difficulties, and cause the righ= t thing to happen (local UA being configured not to expect incoming data in= that format). I think.

=C2=A0 Would setLocalDescription make the necessary modification= s in that case?=C2=A0 =C2=A0=C2=A0What about changes after setLocalDescript= ion has been called?=C2=A0 Are they not allowed?=C2=A0 If they are allowed,= how does the peer connection know what to expect from the other side?=C2= =A0

Seems to me that pc.setLocalDescription would have t= o be called again, otherwise the local PC doesn't know about the change= .

=C2=A0

Jim

=C2=A0

=C2=A0

=C2=A0

From: <= a href=3D"mailto:rtcweb-bounces@ietf.org" target=3D"_blank">rtcweb-bounces@= ietf.org [= mailto:rtcweb-bounces@ietf.org] On Behalf Of Justin Uberti
Sent: Wednesday, February 08, 2012 3:57 PM
To: rtcweb@ietf.org; public-webrtc@w3.org
<= b>Subject: [rtcweb] New JSEP draft posted

=C2=A0

Now available at http://www.ietf.org/id/draft-uberti-rtcweb-jsep= -01.txt

=C2=A0

Includes changes based on implementation feedback, and I believe= it addresses most of the concerns raised in last week's interim meetin= gs:

- Initial documentation provided for each= API call, and what state changes it causes

- More examples, including a complete basic sample appl= ication

- Simplified approach to trickle candidat= e handling

- Resolved co= ncerns about how to separate SDP attributes into media / transport

- Provided encapsulation for SDP blobs an= d ICE candidate lines, in the event we want to change encodings or provide = helper functions for JS

- Provided mechanism for limiting candidates to TURN-only

=

- Resolved several implementation issues<= u>

=C2=A0

=

I have not yet addressed the non-overlapping co= dec concern mentioned in the interim meeting. I think there are ways of han= dling this either in the application or the implementation, but I wanted to= get this -01 out first for feedback.

=C2=A0


--20cf3026697a21f5e204b88f0781-- From HKaplan@acmepacket.com Thu Feb 9 14:40: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 B6E2821E805A for ; Thu, 9 Feb 2012 14:40:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, 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 KS7hsIIHn5RI for ; Thu, 9 Feb 2012 14:40:16 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0383021E8036 for ; Thu, 9 Feb 2012 14:40:15 -0800 (PST) Received: from MAIL1.acmepacket.com (10.0.0.21) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 9 Feb 2012 17:40:13 -0500 Received: from MAIL2.acmepacket.com ([169.254.2.216]) by Mail1.acmepacket.com ([169.254.1.108]) with mapi id 14.01.0270.001; Thu, 9 Feb 2012 17:40:13 -0500 From: Hadriel Kaplan To: Tim Panton Thread-Topic: [rtcweb] Charter reminder Thread-Index: AQHM53vJY6tzDOfnw0GkUoNbM3TUHA== Date: Thu, 9 Feb 2012 22:40:12 +0000 Message-ID: <09015F5C-FA8F-43FB-B22B-5D6C9FB7E58A@acmepacket.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="us-ascii" Content-ID: <58F237DEEB6BA94DB7FC13C4AC22CDB9@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] Charter reminder 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, 09 Feb 2012 22:40:16 -0000 On Feb 7, 2012, at 5:40 PM, Tim Panton wrote: > Only pre-existing IETF documents acceptable here. >=20 > That being the case I think we had better take a look at rfc5456 since it > meets the bulk of the requirements expressed in the charter. RFC 5456 is not an IETF standard, nor even an IETF document. It was an ind= ependent submission to the RFC Editor, which is outside of the IETF. -hadriel From HKaplan@acmepacket.com Thu Feb 9 15:06: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 8251011E8096 for ; Thu, 9 Feb 2012 15:06:28 -0800 (PST) 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 lccLfwYk00FS for ; Thu, 9 Feb 2012 15:06:28 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id C9A7C11E808A for ; Thu, 9 Feb 2012 15:06:27 -0800 (PST) Received: from MAIL1.acmepacket.com (10.0.0.21) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 9 Feb 2012 18:06:26 -0500 Received: from MAIL2.acmepacket.com ([169.254.2.216]) by Mail1.acmepacket.com ([169.254.1.108]) with mapi id 14.01.0270.001; Thu, 9 Feb 2012 18:06:26 -0500 From: Hadriel Kaplan To: Randell Jesup Thread-Topic: [rtcweb] Incoming Call for RTCWeb using SIP Thread-Index: AQHM539yvPbQdq2PzEmltikEEqe/Hg== Date: Thu, 9 Feb 2012 23:06:25 +0000 Message-ID: <70C72869-21CA-494F-993A-5FE09164EA29@acmepacket.com> References: <837E772D16C77141BFA5FEC3F30487FF525B8A98@PACDCEXMB02.cable.comcast.com> <4F30F614.2000403@jesup.org> In-Reply-To: <4F30F614.2000403@jesup.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <6E6C9B84D5940540AF40260079A260C2@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] Incoming Call for RTCWeb using SIP 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, 09 Feb 2012 23:06:28 -0000 I think he's asking about the "signaling", not the "media".=20 Sohel:=20 For the "signaling" to get from a Web Server to a Web Browser behind a NAT,= it would use whatever mechanism the web-developer chooses to use (and whic= h the browser can support). For example, it could be using a websocket to = keep a permanent connection up with the web server to receive incoming mess= ages, or it could be frequently http-polling the web server to learn of inc= oming calls. If it's actually truly "SIP" on the browser-server connection, then it woul= d do something like draft-ibc-sipcore-sip-websocket. But there's no need f= or the messages between the browser and server to be real SIP. The browser= -server application is essentially proprietary, as are its message formats = and semantics. -hadriel On Feb 7, 2012, at 4:59 AM, Randell Jesup wrote: > On 2/6/2012 3:59 PM, Khan, Sohel wrote: >=20 >> |RTC SIP-Web Server|---=E0|NAT|-=E0RTC Web-Client (receiver). >>=20 >> RFC 5128 Section 3.2 Connection reversal is an interesting method that >> we can consider for an incoming call. >>=20 >> http://datatracker.ietf.org/doc/rfc5128/?include_text=3D1 >=20 > Please read up on ICE (another IETF RFC), which is what we're specing Web= RTC to use. >=20 >=20 > --=20 > Randell Jesup > randell-ietf@jesup.org > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From juberti@google.com Fri Feb 10 06:03: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 87F9521F865E for ; Fri, 10 Feb 2012 06:03:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.695 X-Spam-Level: X-Spam-Status: No, score=-102.695 tagged_above=-999 required=5 tests=[AWL=0.281, 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 K9bMOa3qVSUj for ; Fri, 10 Feb 2012 06:03:29 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 04BB021F8631 for ; Fri, 10 Feb 2012 06:03:25 -0800 (PST) Received: by iagf6 with SMTP id f6so390559iag.31 for ; Fri, 10 Feb 2012 06:03:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=g8+wHXFyj1TK9+IaQm3M3hPTKYfm1ODcxDKPbSj0jy4=; b=G/aFpHkcs/SnP59QPQekbyV5u/tLEDaciBrepiye+BuBp5XeOl2FaooDD4f6avybNy Y++o0yygcdvreevfiggHg/yhz18irSdPzx2rnYJS/AKtg5elZvQzqRtioKjtsGSUZMWK HyQlR+iBx/V+s9qfBDZYQa1ftI/iHsOxzCMCU= Received: by 10.42.144.196 with SMTP id c4mr9091118icv.39.1328882605453; Fri, 10 Feb 2012 06:03:25 -0800 (PST) Received: by 10.42.144.196 with SMTP id c4mr9091103icv.39.1328882605357; Fri, 10 Feb 2012 06:03:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.85.132 with HTTP; Fri, 10 Feb 2012 06:03:05 -0800 (PST) In-Reply-To: <4F34FA8E.1020307@ericsson.com> References: <4F34FA8E.1020307@ericsson.com> From: Justin Uberti Date: Fri, 10 Feb 2012 09:03:05 -0500 Message-ID: To: Adam Bergkvist Content-Type: multipart/alternative; boundary=90e6ba21224ba3fa0904b89c9717 X-System-Of-Record: true X-Gm-Message-State: ALoCoQn+JSMTwOkcHJecGU+UAgrKGJ36IUmk1ZxIo3IJgTIbFOb5mcSc6SQmD9OAgi9BNI5fXg2vle2hn4T80I1gMgWHPetdHDrmHZuRSIO9Kw0+WDWy+UxxJ71QB7kBvq7Uxw1wUeqLph8kwPJw0HbO8FfII8pu2g== Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] New JSEP draft posted 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, 10 Feb 2012 14:03:35 -0000 --90e6ba21224ba3fa0904b89c9717 Content-Type: text/plain; charset=UTF-8 On Fri, Feb 10, 2012 at 6:07 AM, Adam Bergkvist wrote: > On 02/08/2012 09:57 PM, Justin Uberti wrote: > >> Now available at http://www.ietf.org/id/draft-**uberti-rtcweb-jsep-01.txt >> >> Includes changes based on implementation feedback, and I believe it >> addresses most of the concerns raised in last week's interim meetings: >> - Initial documentation provided for each API call, and what state >> changes it causes >> - More examples, including a complete basic sample application >> - Simplified approach to trickle candidate handling >> - Resolved concerns about how to separate SDP attributes into media / >> transport >> - Provided encapsulation for SDP blobs and ICE candidate lines, in the >> event we want to change encodings or provide helper functions for JS >> - Provided mechanism for limiting candidates to TURN-only >> - Resolved several implementation issues >> >> I have not yet addressed the non-overlapping codec concern mentioned in >> the interim meeting. I think there are ways of handling this either in >> the application or the implementation, but I wanted to get this -01 out >> first for feedback. >> > > Good to see a concrete JS example. Some comments below. > > I believe the example has a deadlock on the caller side: > * hasCandidates (initially false) is set true by the ice callback > * the ice callback can never trigger before startIce() is called > * maybeSignal(), which calls startIce(), will return early if > hasCandidates is false > You're right. startIce() should be called in start(), if |isCaller| is true. > > Another thing, how are the candidates from the ice callback included in > the offer? The candidate argument from the ice callback is never used. As mentioned in the draft, candidates are included in the offer automatically (if they have already been gathered). In the example, we just wait for the IceCallback to inform us that gathering is complete, and use that to know when to dispatch the offer. > > > /Adam > --90e6ba21224ba3fa0904b89c9717 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Feb 10, 2012 at 6:07 AM, Adam Be= rgkvist <adam.bergkvist@ericsson.com> wrote:
On 02/08/2012 09:57 PM, Justin Uber= ti wrote:
Now available at http://www.ietf.org/id/draft-uberti-rtcwe= b-jsep-01.txt

Includes changes based on implementation feedback, and I believe it
addresses most of the concerns raised in last week's interim meetings:<= br> - Initial documentation provided for each API call, and what state
changes it causes
- More examples, including a complete basic sample application
- Simplified approach to trickle candidate handling
- Resolved concerns about how to separate SDP attributes into media /
transport
- Provided encapsulation for SDP blobs and ICE candidate lines, in the
event we want to change encodings or provide helper functions for JS
- Provided mechanism for limiting candidates to TURN-only
- Resolved several implementation issues

I have not yet addressed the non-overlapping codec concern mentioned in
the interim meeting. I think there are ways of handling this either in
the application or the implementation, but I wanted to get this -01 out
first for feedback.

Good to see a concrete JS example. Some comments below.

I believe the example has a deadlock on the caller side:
* hasCandidates (initially false) is set true by the ice callback
* the ice callback can never trigger before startIce() is called
* maybeSignal(), which calls startIce(), will return early if hasCandidates= is false

You're right. startIce() = should be called in start(), if |isCaller| is true.=C2=A0

Another thing, how are the candidates from the ice callback included in the= offer? The candidate argument from the ice callback is never used.

As mentioned in the draft, candidates are included= in the offer automatically (if they have already been gathered). In the ex= ample, we just wait for the IceCallback to inform us that gathering is comp= lete, and use that to know when to dispatch the offer.


/Adam

--90e6ba21224ba3fa0904b89c9717-- From juberti@google.com Fri Feb 10 08:03: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 859CC21F86F2 for ; Fri, 10 Feb 2012 08:03:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.963 X-Spam-Level: X-Spam-Status: No, score=-101.963 tagged_above=-999 required=5 tests=[AWL=-0.471, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_83=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 HHlTeQalb0X4 for ; Fri, 10 Feb 2012 08:03:13 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7158A21F86F3 for ; Fri, 10 Feb 2012 08:03:13 -0800 (PST) Received: by obbwd15 with SMTP id wd15so4723152obb.31 for ; Fri, 10 Feb 2012 08:03:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=x8balguIJN1ARnuyy6tEQ47rkUuYpsPDUkztmV+VEOA=; b=Oz27uoIxdAP6ZAFjhLEX2tDdhGS53fJd9Bfse493J+BlotntrlrLoCPY1z7x3kGhql yihBbvM4kpByXafJPXfJgp8ZSmg21adY3bzd6V1EpVHap1hHXPdjN7/zfr8IgeYCr9KI AeD+7LgzycjrRDji/vWKPDi3DEFxne5bSczyY= Received: by 10.50.34.202 with SMTP id b10mr11922671igj.30.1328889792978; Fri, 10 Feb 2012 08:03:12 -0800 (PST) Received: by 10.50.34.202 with SMTP id b10mr11922652igj.30.1328889792878; Fri, 10 Feb 2012 08:03:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.85.132 with HTTP; Fri, 10 Feb 2012 08:02:51 -0800 (PST) In-Reply-To: References: <4F34FA8E.1020307@ericsson.com> From: Justin Uberti Date: Fri, 10 Feb 2012 11:02:51 -0500 Message-ID: To: Adam Bergkvist Content-Type: multipart/alternative; boundary=14dae9340f9d0cd77004b89e4426 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkxR6+2GhT7tydnZnx0TQ5et6QjUoP5d7rh2R2HuZVHrVp/HdQrjoLE4FAy/PvZgz8L1xYyR/gSJR8AMDjypqM6BchRHMC6HTiJegjN6e6asrRWwg8BYAzp0oh0CiJDgsx78LJshokUOml2b+upeNg2NYoVSg== Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] New JSEP draft posted 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, 10 Feb 2012 16:03:14 -0000 --14dae9340f9d0cd77004b89e4426 Content-Type: text/plain; charset=UTF-8 Updated sample below. Changes (move of startIce) are in *bold*. var signalingChannel = createSignalingChannel(); var pc = null; var hasCandidates = false; function start(isCaller) { // create a PeerConnection and hook up the IceCallback pc = new webkitPeerConnection( "", function (candidate, moreToFollow) { if (!moreToFollow) { hasCandidates = true; maybeSignal(isCaller); } }); // get the local stream and show it in the local video element navigator.webkitGetUserMedia( {"audio": true, "video": true}, function (localStream) { selfView.src = webkitURL.createObjectURL(localStream); pc.addStream(localStream); maybeSignal(isCaller); } // once remote stream arrives, show it in the remote video element pc.onaddstream = function(evt) { remoteView.src = webkitURL.createObjectURL(evt.stream); }; * // if we're the caller, create and install our offer,* * // and start candidate generation* * if (isCaller) {* * offer = pc.createOffer(null);* * pc.setLocalDescription(SDP_OFFER, offer);* * pc.startIce();* * }* } function maybeSignal(isCaller) { // only signal once we have a local stream and local candidates if (localStreams.size() == 0 || !hasCandidates) return; if (isCaller) { * offer = pc.localDescription;* signalingChannel.send( JSON.stringify({ "type": "offer", "sdp": offer })); } else { // if we're the callee, generate, apply, and send the answer answer = pc.createAnswer(pc.remoteDescription, null); pc.setLocalDescription(SDP_ANSWER, answer); signalingChannel.send( JSON.stringify({ "type": "answer", "sdp": answer })); } } signalingChannel.onmessage = function(evt) { var msg = JSON.parse(evt.data); if (msg.type == "offer") { // create the PeerConnection start(false); // feed the received offer into the PeerConnection and // start candidate generation pc.setRemoteDescription(PeerConnection.SDP_OFFER, msg.sdp); pc.startIce(); } else if (msg.type == "answer") { // feed the answer into the PeerConnection to complete setup pc.setRemoteDescription(PeerConnection.SDP_ANSWER, msg.sdp); } On Fri, Feb 10, 2012 at 9:03 AM, Justin Uberti wrote: > > > On Fri, Feb 10, 2012 at 6:07 AM, Adam Bergkvist < > adam.bergkvist@ericsson.com> wrote: > >> On 02/08/2012 09:57 PM, Justin Uberti wrote: >> >>> Now available at http://www.ietf.org/id/draft-** >>> uberti-rtcweb-jsep-01.txt >>> >>> Includes changes based on implementation feedback, and I believe it >>> addresses most of the concerns raised in last week's interim meetings: >>> - Initial documentation provided for each API call, and what state >>> changes it causes >>> - More examples, including a complete basic sample application >>> - Simplified approach to trickle candidate handling >>> - Resolved concerns about how to separate SDP attributes into media / >>> transport >>> - Provided encapsulation for SDP blobs and ICE candidate lines, in the >>> event we want to change encodings or provide helper functions for JS >>> - Provided mechanism for limiting candidates to TURN-only >>> - Resolved several implementation issues >>> >>> I have not yet addressed the non-overlapping codec concern mentioned in >>> the interim meeting. I think there are ways of handling this either in >>> the application or the implementation, but I wanted to get this -01 out >>> first for feedback. >>> >> >> Good to see a concrete JS example. Some comments below. >> >> I believe the example has a deadlock on the caller side: >> * hasCandidates (initially false) is set true by the ice callback >> * the ice callback can never trigger before startIce() is called >> * maybeSignal(), which calls startIce(), will return early if >> hasCandidates is false >> > > You're right. startIce() should be called in start(), if |isCaller| is > true. > >> >> Another thing, how are the candidates from the ice callback included in >> the offer? The candidate argument from the ice callback is never used. > > > As mentioned in the draft, candidates are included in the offer > automatically (if they have already been gathered). In the example, we just > wait for the IceCallback to inform us that gathering is complete, and use > that to know when to dispatch the offer. > >> >> >> /Adam >> > > --14dae9340f9d0cd77004b89e4426 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Updated sample below. Changes (move of startIce) are in bold.

=C2=A0 =C2=A0 =C2=A0=C2=A0var signalingChannel =3D createSignalingChannel();
=C2=A0 =C2= =A0var pc =3D null;
=C2=A0 =C2=A0var hasCa= ndidates =3D false;

=C2=A0 =C2=A0function start(isCaller) {
=C2=A0 =C2=A0 =C2=A0//= create a PeerConnection and hook up the IceCallback
=C2=A0 =C2=A0 =C2=A0pc =3D new w= ebkitPeerConnection(
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 "", function (candidate, moreToFollow) {
=C2=A0 =C2=A0= =C2=A0 =C2=A0if (!moreToFollow) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0hasCandidates =3D true;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0maybeSignal(isCaller= );
=C2=A0 = =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0})= ;

=C2=A0 =C2=A0= =C2=A0// get the local stream and show it in the local video element
=C2=A0 =C2=A0 =C2=A0na= vigator.webkitGetUserMedia(
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{"audio&quo= t;: true, "video": true}, function (localStream) {
=C2=A0 =C2=A0 =C2=A0 = =C2=A0selfView.src =3D webkitURL.createObjectURL(localStream);
=
=C2=A0 =C2=A0 =C2=A0 = =C2=A0pc.addStream(localStream);
=C2=A0 =C2=A0 =C2=A0 = =C2=A0maybeSignal(isCaller); =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0}

=C2=A0 = =C2=A0 =C2=A0// once remote stream arrives, show it in the remote video ele= ment
=C2= =A0 =C2=A0 =C2=A0pc.onaddstream =3D function(evt) {
=C2=A0 =C2=A0 =C2=A0 = =C2=A0remoteView.src =3D webkitURL.createObjectURL(evt.stream);
=C2=A0 =C2=A0 =C2=A0}= ;

=C2=A0 = =C2=A0 =C2=A0// if we're the caller, create and install our offer,
=C2= =A0 =C2=A0 =C2=A0// and start candidate generation
=C2=A0 =C2=A0 =C2= =A0if (isCaller) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0offer =3D pc.createOffer(null);<= /b>
=C2= =A0 =C2=A0 =C2=A0 =C2=A0pc.setLocalDescription(SDP_OFFER, offer);
=C2=A0 =C2=A0 =C2= =A0 =C2=A0pc.startIce();
=C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0}

= =C2=A0 =C2=A0function maybe= Signal(isCaller) {
=C2=A0 =C2=A0 =C2=A0// only signal once we have a local stream and= local candidates
=C2=A0 =C2=A0 =C2=A0if= (localStreams.size() =3D=3D 0 || !hasCandidates) return;
= =C2=A0 =C2=A0 =C2=A0if (isC= aller) {
= =C2=A0 =C2=A0 =C2=A0 =C2=A0offer =3D pc.localDescription;
=C2=A0 =C2=A0 =C2=A0 = =C2=A0signalingChannel.send(
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0JSON.stringify(= { "type": "offer", "sdp": offer }));=C2=A0
=C2=A0 =C2=A0 =C2=A0} = else {
=C2= =A0 =C2=A0 =C2=A0 =C2=A0// if we're the callee, generate, apply, and se= nd the answer
=C2=A0 =C2=A0 =C2=A0 =C2=A0answer =3D pc.createAnswer(pc.remoteDescript= ion, null);
=C2=A0 =C2=A0 =C2=A0 = =C2=A0pc.setLocalDescription(SDP_ANSWER, answer);
=C2=A0 =C2=A0 =C2=A0 =C2=A0signalin= gChannel.send(
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0JSON.stringify({ "type&q= uot;: "answer", "sdp": answer })); =C2=A0
=C2=A0 =C2=A0 =C2=A0}<= /font>
=C2=A0 =C2= =A0}

<= /font>
=C2=A0 =C2= =A0signalingChannel.onmessage =3D function(evt) {
=C2=A0 =C2=A0 =C2=A0va= r msg =3D JSON.parse(evt.data);
=C2=A0 =C2=A0 =C2=A0if (msg.type =3D=3D "offer&q= uot;) {
= =C2=A0 =C2=A0 =C2=A0 =C2=A0// create the PeerConnection
=C2=A0 =C2=A0 =C2=A0 = =C2=A0start(false);
=C2=A0 =C2=A0 =C2=A0 =C2=A0// feed the received offer into the Pe= erConnection and
=C2=A0 =C2=A0 =C2=A0 =C2=A0// start candidate generation
=C2=A0 =C2=A0 =C2=A0 = =C2=A0pc.setRemoteDescription(PeerConnection.SDP_OFFER, msg.sdp);
=C2=A0 =C2=A0 =C2= =A0 =C2=A0pc.startIce();
=C2=A0 =C2=A0 =C2=A0} else = if (msg.type =3D=3D "answer") { =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 = =C2=A0// feed the answer into the PeerConnection to complete setup =C2=A0= =C2=A0
=C2= =A0 =C2=A0 =C2=A0 =C2=A0pc.setRemoteDescription(PeerConnection.SDP_ANSWER, = msg.sdp);
=C2=A0 =C2=A0 =C2=A0}<= /font>


On Fri, Feb 10, 2= 012 at 9:03 AM, Justin Uberti <juberti@google.com> wrote:


On Fri, Feb 10, 2012 at 6:07 AM, Adam Bergkvist <a= dam.bergkvist@ericsson.com> wrote:
On 02/08/2012 09:57 PM, Justin Uberti wrote:
Now available at http://www.ietf.org/id/draft-uberti-rtcwe= b-jsep-01.txt

Includes changes based on implementation feedback, and I believe it
addresses most of the concerns raised in last week's interim meetings:<= br> - Initial documentation provided for each API call, and what state
changes it causes
- More examples, including a complete basic sample application
- Simplified approach to trickle candidate handling
- Resolved concerns about how to separate SDP attributes into media /
transport
- Provided encapsulation for SDP blobs and ICE candidate lines, in the
event we want to change encodings or provide helper functions for JS
- Provided mechanism for limiting candidates to TURN-only
- Resolved several implementation issues

I have not yet addressed the non-overlapping codec concern mentioned in
the interim meeting. I think there are ways of handling this either in
the application or the implementation, but I wanted to get this -01 out
first for feedback.

Good to see a concrete JS example. Some comments below.

I believe the example has a deadlock on the caller side:
* hasCandidates (initially false) is set true by the ice callback
* the ice callback can never trigger before startIce() is called
* maybeSignal(), which calls startIce(), will return early if hasCandidates= is false

You're right.= startIce() should be called in start(), if |isCaller| is true.=C2=A0

Another thing, how are the candidates from the ice callback included in the= offer? The candidate argument from the ice callback is never used.

As mentioned in the draft, candidates are in= cluded in the offer automatically (if they have already been gathered). In = the example, we just wait for the IceCallback to inform us that gathering i= s complete, and use that to know when to dispatch the offer.


/Adam


--14dae9340f9d0cd77004b89e4426-- From ibc@aliax.net Mon Feb 13 03:25: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 89CAC21F85B7 for ; Mon, 13 Feb 2012 03:25:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.719 X-Spam-Level: X-Spam-Status: No, score=-1.719 tagged_above=-999 required=5 tests=[AWL=-0.901, BAYES_20=-0.74, 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 zvwZXAxe4rCh for ; Mon, 13 Feb 2012 03:25:44 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id DCF2521F85AA for ; Mon, 13 Feb 2012 03:25:43 -0800 (PST) Received: by vcbfk14 with SMTP id fk14so3535458vcb.31 for ; Mon, 13 Feb 2012 03:25:43 -0800 (PST) Received: by 10.220.156.204 with SMTP id y12mr8888021vcw.12.1329132343153; Mon, 13 Feb 2012 03:25:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.4.149 with HTTP; Mon, 13 Feb 2012 03:25:23 -0800 (PST) In-Reply-To: <837E772D16C77141BFA5FEC3F30487FF525B8A98@PACDCEXMB02.cable.comcast.com> References: <837E772D16C77141BFA5FEC3F30487FF525B8A98@PACDCEXMB02.cable.comcast.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 13 Feb 2012 12:25:23 +0100 Message-ID: To: "Khan, Sohel" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlkvkAtQSJhHIA+18DVbOMnWKrW++ie+sEVnC+5NsVupe5Rwxs3auBvyJQw4QXn6CShcpzg Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Incoming Call for RTCWeb using SIP 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, 13 Feb 2012 11:25:44 -0000 2012/2/6 Khan, Sohel : > Please assume for this discussion, =C2=A0RTCWeb=C2=A0 uses SIP. That is indeed a wrong assumption (unless you use SIP over WebSocket). The WebRTC browser uses no special transport/signaling for WebRTC communications. It can only use existing mechanisms (HTTP, WebSocket or proprietary protocols via plugins). --=20 I=C3=B1aki Baz Castillo From fluffy@iii.ca Mon Feb 13 07:10: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 EF03D21F84BD for ; Mon, 13 Feb 2012 07:10:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.597 X-Spam-Level: X-Spam-Status: No, score=-1.597 tagged_above=-999 required=5 tests=[AWL=-1.764, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, J_CHICKENPOX_23=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 u7CK3jaIqdvk for ; Mon, 13 Feb 2012 07:10:11 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id F06A621F84B5 for ; Mon, 13 Feb 2012 07:10:10 -0800 (PST) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 160F122E25B; Mon, 13 Feb 2012 10:10:03 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4F297011.1040507@jesup.org> Date: Mon, 13 Feb 2012 08:10:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F234B8B.4020204@jesup.org> <4F295660.3060001@jesup.org> <4F297011.1040507@jesup.org> To: Randell Jesup X-Mailer: Apple Mail (2.1084) Cc: "rtcweb@ietf.org" , public-webrtc@w3.org Subject: Re: [rtcweb] JS app interaction with congestion control 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, 13 Feb 2012 15:10:12 -0000 There are really a lot of things that are along the lines of of = providing JS control of echo cancellation, bandwidth etc. I'd like to = figure out an bit of extensible framework for adding these types of = things. It might be that in the end we end up with exactly this but we = have been talking about some other ways of doing it to - I think Dan is = going to send a proposal to the list at some point.=20 On Feb 1, 2012, at 10:02 AM, Randell Jesup wrote: > This really is almost all W3c stuff; cc'ing that list where most = discussion should occur. >=20 > Updated suggestion based on Justin's comments: (largely for W3C = discussion)=20 >=20 > This is rough, and a first cut, but we need to start somewhere.=20 >=20 > I propose we add a callback on PeerConnection and some attributes on = it=20 > and MediaTracks:=20 >=20 > {=20 > ...=20 > // allow app to limit total bitrate used for the PeerConnection=20 > attribute unsigned long maxBitrate;=20 > attribute readonly unsigned long currentBitrate; // [Open issue] = - how much smoothing?=20 >=20 > attribute Function? onBitrateChange;=20 > // don't notify until change since last notify is more than this=20= > attribute unsigned long minBitrateChangeToNotify;=20 > attribute Function? onResolutionChange; // not strictly needed=20 >=20 > // These are global settings that can be overridden on a per-track = basis=20 > attribute float minFramerate;=20 > attribute float maxFramerate; // might not be needed=20 > attribute boolean preferMotion; // false means preference for = Resolution=20 > }=20 >=20 >=20 > To each MediaTrack:=20 >=20 > {=20 > ...=20 > // If the app bumps up the currentBitrate of one track and doesn't = lower another track, the=20 > // system will make cuts to keep the total bitrate within bounds.=20= > attribute unsigned long currentBitrate;=20 > attribute short priority; // for allocating bits=20 >=20 > // The rest of these are for video (is short guaranteed enough, = always? Probably)=20 > attribute unsigned short width; // Let app override the values = chosen automatically=20 > attribute unsigned short height;=20 > attribute float framerate;=20 > attribute float minFramerate;=20 > attribute float maxFramerate; // might not be needed=20 > attribute boolean preferMotion; // false means preference for = Resolution=20 >=20 > // typically derived from QP=20 > attribute readonly unsigned short videoQuality;=20 > // audioQuality?? (samplerate?)=20 >=20 > }=20 >=20 > Should some of these be echoed in MediaTrackLists or MediaStreams?=20 >=20 >=20 > --=20 > Randell Jesup >=20 > randell-ietf@jesup.org From fluffy@iii.ca Mon Feb 13 07:18: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 C79EC21F851B for ; Mon, 13 Feb 2012 07:18:59 -0800 (PST) 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=2.700, BAYES_00=-2.599, J_CHICKENPOX_29=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 NPtDugJZN9wn for ; Mon, 13 Feb 2012 07:18:58 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 982BB21F851A for ; Mon, 13 Feb 2012 07:18:58 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AucGAAQpOU+rRDoI/2dsb2JhbABDgxGsfoEHgXIBAQEDARIBFFIFCwsOAwQBAQEnB0YJCAYTCRmHWgmdKwGWZotDBQYCBQEJAgQDAQYBBAMBAQIBAgMBAQMDBQIEBwIdAQUUE4MeBQY9WYJgYwSISpJCjSo X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="30154233" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 13 Feb 2012 15:18:54 +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 q1DFIre8022486; Mon, 13 Feb 2012 15:18:53 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Cullen Jennings In-Reply-To: Date: Mon, 13 Feb 2012 08:18:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <22A0A0A4-5765-47FC-97E0-3C5B0AE2753B@iii.ca> References: <4F342C99.50403@alvestrand.no> To: Justin Uberti X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] New JSEP draft posted 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, 13 Feb 2012 15:19:00 -0000 I think a good way to indicate what could be changed in the SDP would be = a table where for each part of SDP, we listed being something that can = be changed, or can not be changed, or unknown and it might work on some = browsers and not on others. This allows the browser vendors to have a = set of stuff they clearly know will not be changed, and the JS = implementers to have a list of changes they know will work.=20 I'll start a separate thread asking what needs to be changeable. On Feb 9, 2012, at 2:52 PM, Justin Uberti wrote: > I agree we should provide guidance here on what can be changed, and = fail any edits that are disallowed. We can do this while nailing down = exactly what parts of SDP all implementations must support. >=20 > On Thu, Feb 9, 2012 at 4:47 PM, Jim Barnett = wrote: > So we will need to specify which aspects of an offer can be modified = before setLocalDescription is called (or, equivalently, specify the = conditions under which setLocalDescription must fail). For = compatibility reasons we wouldn=92t want to allow the individual browser = vendors decide which modifications to accept. Could we define an API on = offer that would allow only the legal changes to be made, or would that = be impractical? If changes to the offer went through the API, it might = be possible to track if changes had been made since the last call to = setLocalDescription, and at least issue a warning if the application = tried to send an offer that was out of synch with the local description.=20= >=20 > =20 >=20 > I suppose it=92s a matter of taste how much we try to keep app = developers from shooting themselves in the foot, but it seems to me = that it=92s dangerous to tell them that they can edit the offer object = or the resulting SDP when there are so many ways for that to fail. >=20 > =20 >=20 > - Jim >=20 > =20 >=20 > From: Harald Alvestrand [mailto:harald@alvestrand.no]=20 > Sent: Thursday, February 09, 2012 3:29 PM > To: Jim Barnett > Cc: Justin Uberti; rtcweb@ietf.org; public-webrtc@w3.org > Subject: Re: [rtcweb] New JSEP draft posted >=20 > =20 >=20 > On 02/09/2012 07:26 AM, Jim Barnett wrote: >=20 > Justin, >=20 > What happens if the application JavaScript modifies the offer? Take = the offer generation in example 7.1: >=20 > OffererJS->OffererUA: pc =3D new PeerConnection(); > OffererJS->OffererUA: pc.addStream(localStream, null); >=20 > OffererJS->OffererUA: pc.startIce(); >=20 > OffererUA->OffererJS: iceCallback(candidate, false); >=20 > OffererJS->OffererUA: offer =3D pc.createOffer(null); >=20 > OffererJS->OffererUA: pc.setLocalDescription(SDP_OFFER, = offer.toSdp()); >=20 > OffererJS->AnswererJS: {"type":"OFFER", "sdp":""} >=20 > =20 >=20 > Could the JS modify the offer between steps 5 and 6 or between steps 6 = and 7? For example, between steps 5 and 6, could the JS add a stream = for which pc.addStream had not been called previously? >=20 > The JS would not know what to enter for an added stream, I think. Most = probably an attempt to do this should result in the SetLocalDescription = being invalid, and thus rejected. >=20 > Removing codecs, for instance, would be expected to cause no = difficulties, and cause the right thing to happen (local UA being = configured not to expect incoming data in that format). I think. >=20 >=20 > Would setLocalDescription make the necessary modifications in that = case? What about changes after setLocalDescription has been called? = Are they not allowed? If they are allowed, how does the peer connection = know what to expect from the other side?=20 >=20 > Seems to me that pc.setLocalDescription would have to be called again, = otherwise the local PC doesn't know about the change. >=20 >=20 > =20 >=20 > Jim >=20 > =20 >=20 > =20 >=20 > =20 >=20 > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On = Behalf Of Justin Uberti > Sent: Wednesday, February 08, 2012 3:57 PM > To: rtcweb@ietf.org; public-webrtc@w3.org > Subject: [rtcweb] New JSEP draft posted >=20 > =20 >=20 > Now available at = http://www.ietf.org/id/draft-uberti-rtcweb-jsep-01.txt >=20 > =20 >=20 > Includes changes based on implementation feedback, and I believe it = addresses most of the concerns raised in last week's interim meetings: >=20 > - Initial documentation provided for each API call, and what state = changes it causes >=20 > - More examples, including a complete basic sample application >=20 > - Simplified approach to trickle candidate handling >=20 > - Resolved concerns about how to separate SDP attributes into media / = transport >=20 > - Provided encapsulation for SDP blobs and ICE candidate lines, in the = event we want to change encodings or provide helper functions for JS >=20 > - Provided mechanism for limiting candidates to TURN-only >=20 > - Resolved several implementation issues >=20 > =20 >=20 > I have not yet addressed the non-overlapping codec concern mentioned = in the interim meeting. I think there are ways of handling this either = in the application or the implementation, but I wanted to get this -01 = out first for feedback. >=20 > =20 >=20 >=20 From fluffy@iii.ca Mon Feb 13 07:19: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 B885021F851A for ; Mon, 13 Feb 2012 07:19:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.925 X-Spam-Level: X-Spam-Status: No, score=-2.925 tagged_above=-999 required=5 tests=[AWL=-0.326, 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 uuk8BZeZkCln for ; Mon, 13 Feb 2012 07:19:13 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 243FD21F850D for ; Mon, 13 Feb 2012 07:19:13 -0800 (PST) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 8A70B22E258 for ; Mon, 13 Feb 2012 10:19:12 -0500 (EST) From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Feb 2012 08:19:11 -0700 Message-Id: <29CD92BB-6764-4B87-AA99-ADB4B9685059@iii.ca> To: rtcweb@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [rtcweb] What parts of SDP need to changeable by the JS application 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, 13 Feb 2012 15:19:13 -0000 I'd like to figure out what parts of the SDP that the JS App needs to be = able to change.=20 The one clear example I have heard is removing a codec that the App does = not want to use. Are there others?=20= From ekr@rtfm.com Mon Feb 13 07:21: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 43B5721F850D for ; Mon, 13 Feb 2012 07:21:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.917 X-Spam-Level: X-Spam-Status: No, score=-102.917 tagged_above=-999 required=5 tests=[AWL=0.060, 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 Dvk5NV+U9Gj5 for ; Mon, 13 Feb 2012 07:21:27 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 978D621F8594 for ; Mon, 13 Feb 2012 07:21:27 -0800 (PST) Received: by vbbfr13 with SMTP id fr13so3726674vbb.31 for ; Mon, 13 Feb 2012 07:21:26 -0800 (PST) Received: by 10.52.38.10 with SMTP id c10mr7185661vdk.58.1329146486727; Mon, 13 Feb 2012 07:21:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.71.19 with HTTP; Mon, 13 Feb 2012 07:20:46 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: <29CD92BB-6764-4B87-AA99-ADB4B9685059@iii.ca> References: <29CD92BB-6764-4B87-AA99-ADB4B9685059@iii.ca> From: Eric Rescorla Date: Mon, 13 Feb 2012 07:20:46 -0800 Message-ID: To: Cullen Jennings Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQn1k8V5hb+muRnfnV7dwovkq0t93+yOdeismYV4udXizRWLXymXhldPRzGh5FFxFoIzuh5P Cc: rtcweb@ietf.org Subject: Re: [rtcweb] What parts of SDP need to changeable by the JS application 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, 13 Feb 2012 15:21:29 -0000 On Mon, Feb 13, 2012 at 7:19 AM, Cullen Jennings wrote: > > I'd like to figure out what parts of the SDP that the JS App needs to be able to change. > > The one clear example I have heard is removing a codec that the App does not want to use. > > Are there others? Hadriel suggested adding ICE Candidates. [I'm not taking a position on this.] -Ekr From Jim.Barnett@genesyslab.com Mon Feb 13 07:24: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 5A5B421F862A for ; Mon, 13 Feb 2012 07:24:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J014N8GTuJr9 for ; Mon, 13 Feb 2012 07:24:17 -0800 (PST) Received: from relay-out1.dc.genesyslab.com (relay-out1.dc.genesyslab.com [198.49.180.220]) by ietfa.amsl.com (Postfix) with ESMTP id AF76621F858F for ; Mon, 13 Feb 2012 07:24:17 -0800 (PST) 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 q1DFOGx5005794; Mon, 13 Feb 2012 07:24:16 -0800 (PST) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 Feb 2012 07:24:16 -0800 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: Mon, 13 Feb 2012 07:23:43 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] What parts of SDP need to changeable by the JSapplication Thread-Index: AczqYytK+aIjOpsCSLWFxBLVma2TgQAACzsg References: <29CD92BB-6764-4B87-AA99-ADB4B9685059@iii.ca> From: "Jim Barnett" To: "Eric Rescorla" , "Cullen Jennings" X-OriginalArrivalTime: 13 Feb 2012 15:24:16.0643 (UTC) FILETIME=[8C7AED30:01CCEA63] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] What parts of SDP need to changeable by the JSapplication 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, 13 Feb 2012 15:24:18 -0000 If ICE is under browser control, how would the JS app be able to _add_ candidates? Where would it get them? Though I can imagine that it might want to remove candidates. - Jim -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Eric Rescorla Sent: Monday, February 13, 2012 10:21 AM To: Cullen Jennings Cc: rtcweb@ietf.org Subject: Re: [rtcweb] What parts of SDP need to changeable by the JSapplication On Mon, Feb 13, 2012 at 7:19 AM, Cullen Jennings wrote: > > I'd like to figure out what parts of the SDP that the JS App needs to be able to change. > > The one clear example I have heard is removing a codec that the App does not want to use. > > Are there others? Hadriel suggested adding ICE Candidates. [I'm not taking a position on this.] -Ekr _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From ekr@rtfm.com Mon Feb 13 07:28: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 3A75C21F8649 for ; Mon, 13 Feb 2012 07:28:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.919 X-Spam-Level: X-Spam-Status: No, score=-102.919 tagged_above=-999 required=5 tests=[AWL=0.058, 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 eahJ5zbP5R4X for ; Mon, 13 Feb 2012 07:28:32 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 346E221F8648 for ; Mon, 13 Feb 2012 07:28:32 -0800 (PST) Received: by vcbfk14 with SMTP id fk14so3714833vcb.31 for ; Mon, 13 Feb 2012 07:28:31 -0800 (PST) Received: by 10.52.27.70 with SMTP id r6mr7180715vdg.41.1329146911146; Mon, 13 Feb 2012 07:28:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.71.19 with HTTP; Mon, 13 Feb 2012 07:27:51 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: References: <29CD92BB-6764-4B87-AA99-ADB4B9685059@iii.ca> From: Eric Rescorla Date: Mon, 13 Feb 2012 07:27:51 -0800 Message-ID: To: Jim Barnett Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlFAISkU5ktawqa1AjnqG4Dt1BESTLu+R1FDRW7L/RdA7XenU8rxMiyKkCVBbDCac6cRTCz Cc: rtcweb@ietf.org Subject: Re: [rtcweb] What parts of SDP need to changeable by the JSapplication 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, 13 Feb 2012 15:28:33 -0000 On Mon, Feb 13, 2012 at 7:23 AM, Jim Barnett w= rote: > If ICE is under browser control, how would the JS app be able to _add_ > candidates? =A0Where would it get them? =A0Though I can imagine that it > might want to remove candidates. IIRC Hadriel's suggestion was to enable SBCs to steer media. -Ekr From pravindran@sonusnet.com Mon Feb 13 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 285A021F87CC for ; Mon, 13 Feb 2012 10:36:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MPUcoiOM42wb for ; Mon, 13 Feb 2012 10:36:25 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id E63DA21F87CB for ; Mon, 13 Feb 2012 10:36:24 -0800 (PST) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q1DIb9KE011805; Mon, 13 Feb 2012 13:37:09 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 Feb 2012 13:36:21 -0500 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Feb 2012 00:06:29 +0530 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; Tue, 14 Feb 2012 00:06:28 +0530 From: "Ravindran, Parthasarathi" To: Justin Uberti , "rtcweb@ietf.org" , "public-webrtc@w3.org" Thread-Topic: Single offer with multiple answer handling in JSEP [was RE: [rtcweb] New JSEP draft posted] Thread-Index: AQHM6n5lZgjOEHxBM02vFGfTPVw5uw== Date: Mon, 13 Feb 2012 18:36:28 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E03F7E7@inba-mail01.sonusnet.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: multipart/alternative; boundary="_000_387F9047F55E8C42850AD6B3A7A03C6C0E03F7E7inbamail01sonus_" MIME-Version: 1.0 X-OriginalArrivalTime: 13 Feb 2012 18:36:29.0264 (UTC) FILETIME=[66753D00:01CCEA7E] Subject: [rtcweb] Single offer with multiple answer handling in JSEP [was RE: New JSEP draft posted] 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, 13 Feb 2012 18:36:26 -0000 --_000_387F9047F55E8C42850AD6B3A7A03C6C0E03F7E7inbamail01sonus_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSnVzdGluLA0KDQpJbiB0aGUgZHJhZnQsIGl0IGlzIG5vdCBzcGVsbGVkIG91dCBleHBsaWNp dGx5IHdoYXQgaXMgdGhlIGV4cGVjdGVkIGJlaGF2aW9yIGluIG9mZmVyZXIgYnJvd3NlciBpbiBj YXNlIG11bHRpcGxlIGFuc3dlciBpcyByZWNlaXZlZCBmb3Igc2luZ2xlIG9mZmVyLiBPZmZlci9h bnN3ZXIgZXhjaGFuZ2UgaW4gb2ZmZXJlciBpcyBhcyBmb2xsb3dzOg0KDQoNCk9mZmVyZXJKUy0+ T2ZmZXJlclVBOiB2YXIgb2ZmZXIgPSBwYy5jcmVhdGVPZmZlcihudWxsKTsNCk9mZmVyZXJKUy0+ T2ZmZXJlclVBOiBwYy5zZXRMb2NhbERlc2NyaXB0aW9uKFNEUF9PRkZFUiwgb2ZmZXIpOw0KDQpP ZmZlcmVySlMtPk9mZmVyZXJVQTogIHBjLnNldFJlbW90ZURlc2NyaXB0aW9uKFNEUF9BTlNXRVIs IGFuc3dlcjEpOw0KDQpPZmZlcmVyVUEtPkFuc3dlcmVyMVVBOiA8bWVkaWE+DQoNCk9mZmVyZXJK Uy0+T2ZmZXJlclVBOiAgcGMuc2V0UmVtb3RlRGVzY3JpcHRpb24oU0RQX0FOU1dFUiwgYW5zd2Vy Mik7DQoNCk9mZmVyZXJVQS0+QW5zd2VyZXI/VUE6IDxtZWRpYT4/DQoNCk15IHVuZGVyc3RhbmRp bmcgaXMgdGhhdCDigJxhbnN3ZXIy4oCdIHdpbGwgdXBkYXRlIOKAnGFuc3dlcjHigJ0gaW4gYnJv d3NlciBhbmQgc3RhcnRpbmcgc2VuZGluZy9yZWNlaXZpbmcgbWVkaWEgdG93YXJkcyBhbnN3ZXIy IG1lZGlhIElQIGFuZCBwb3J0LiBDb3VsZCB5b3UgcGxlYXNlIGV4cGxhaW4gdGhlIGV4cGVjdGVk IGJlaGF2aW9yIGluIG9mZmVyZXIgYnJvd3NlciB3aGV0aGVyIGl0IHVwZGF0ZXMgdGhlIG1lZGlh IHN0cmVhbSBiYXNlZCBvbiB0aGUgbGFzdCBhbnN3ZXIgb3IgbWl4ZXMgYm90aCBhbnN3ZXJlci4N Cg0KVGhhbmtzDQpQYXJ0aGENCg0KRnJvbTogcnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0 bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEp1c3RpbiBVYmVydGkNClNl bnQ6IFRodXJzZGF5LCBGZWJydWFyeSAwOSwgMjAxMiAyOjI3IEFNDQpUbzogcnRjd2ViQGlldGYu b3JnOyBwdWJsaWMtd2VicnRjQHczLm9yZw0KU3ViamVjdDogW3J0Y3dlYl0gTmV3IEpTRVAgZHJh ZnQgcG9zdGVkDQoNCk5vdyBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFm dC11YmVydGktcnRjd2ViLWpzZXAtMDEudHh0DQoNCkluY2x1ZGVzIGNoYW5nZXMgYmFzZWQgb24g aW1wbGVtZW50YXRpb24gZmVlZGJhY2ssIGFuZCBJIGJlbGlldmUgaXQgYWRkcmVzc2VzIG1vc3Qg b2YgdGhlIGNvbmNlcm5zIHJhaXNlZCBpbiBsYXN0IHdlZWsncyBpbnRlcmltIG1lZXRpbmdzOg0K LSBJbml0aWFsIGRvY3VtZW50YXRpb24gcHJvdmlkZWQgZm9yIGVhY2ggQVBJIGNhbGwsIGFuZCB3 aGF0IHN0YXRlIGNoYW5nZXMgaXQgY2F1c2VzDQotIE1vcmUgZXhhbXBsZXMsIGluY2x1ZGluZyBh IGNvbXBsZXRlIGJhc2ljIHNhbXBsZSBhcHBsaWNhdGlvbg0KLSBTaW1wbGlmaWVkIGFwcHJvYWNo IHRvIHRyaWNrbGUgY2FuZGlkYXRlIGhhbmRsaW5nDQotIFJlc29sdmVkIGNvbmNlcm5zIGFib3V0 IGhvdyB0byBzZXBhcmF0ZSBTRFAgYXR0cmlidXRlcyBpbnRvIG1lZGlhIC8gdHJhbnNwb3J0DQot IFByb3ZpZGVkIGVuY2Fwc3VsYXRpb24gZm9yIFNEUCBibG9icyBhbmQgSUNFIGNhbmRpZGF0ZSBs aW5lcywgaW4gdGhlIGV2ZW50IHdlIHdhbnQgdG8gY2hhbmdlIGVuY29kaW5ncyBvciBwcm92aWRl IGhlbHBlciBmdW5jdGlvbnMgZm9yIEpTDQotIFByb3ZpZGVkIG1lY2hhbmlzbSBmb3IgbGltaXRp bmcgY2FuZGlkYXRlcyB0byBUVVJOLW9ubHkNCi0gUmVzb2x2ZWQgc2V2ZXJhbCBpbXBsZW1lbnRh dGlvbiBpc3N1ZXMNCg0KSSBoYXZlIG5vdCB5ZXQgYWRkcmVzc2VkIHRoZSBub24tb3ZlcmxhcHBp bmcgY29kZWMgY29uY2VybiBtZW50aW9uZWQgaW4gdGhlIGludGVyaW0gbWVldGluZy4gSSB0aGlu ayB0aGVyZSBhcmUgd2F5cyBvZiBoYW5kbGluZyB0aGlzIGVpdGhlciBpbiB0aGUgYXBwbGljYXRp b24gb3IgdGhlIGltcGxlbWVudGF0aW9uLCBidXQgSSB3YW50ZWQgdG8gZ2V0IHRoaXMgLTAxIG91 dCBmaXJzdCBmb3IgZmVlZGJhY2suDQo= --_000_387F9047F55E8C42850AD6B3A7A03C6C0E03F7E7inbamail01sonus_ 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 Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2lu OjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHls ZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIEp1c3Rpbiw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPkluIHRoZSBkcmFmdCwgaXQgaXMgbm90IHNwZWxsZWQgb3V0IGV4cGxpY2l0bHkg d2hhdCBpcyB0aGUgZXhwZWN0ZWQgYmVoYXZpb3IgaW4gb2ZmZXJlciBicm93c2VyIGluIGNhc2Ug bXVsdGlwbGUgYW5zd2VyIGlzIHJlY2VpdmVkIGZvciBzaW5nbGUgb2ZmZXIuIE9mZmVyL2Fuc3dl cg0KIGV4Y2hhbmdlIGluIG9mZmVyZXIgaXMgYXMgZm9sbG93czo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHByZT5PZmZlcmVySlMt Jmd0O09mZmVyZXJVQTogdmFyIG9mZmVyID0gcGMuY3JlYXRlT2ZmZXIobnVsbCk7PG86cD48L286 cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5PZmZlcmVySlMtJmd0O09m ZmVyZXJVQTogcGMuc2V0TG9jYWxEZXNjcmlwdGlvbihTRFBfT0ZGRVIsIG9mZmVyKTs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cHJlPk9mZmVyZXJKUy0mZ3Q7T2ZmZXJlclVBOiZuYnNwOyBwYy5z ZXRSZW1vdGVEZXNjcmlwdGlvbihTRFBfQU5TV0VSLCBhbnN3ZXIxKTs8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT5PZmZlcmVyVUEtJmd0O0Fuc3dlcmVyMVVBOiAmbHQ7bWVkaWEmZ3Q7PG86cD48L286 cD48L3ByZT4NCjxwcmU+T2ZmZXJlckpTLSZndDtPZmZlcmVyVUE6Jm5ic3A7IHBjLnNldFJlbW90 ZURlc2NyaXB0aW9uKFNEUF9BTlNXRVIsIGFuc3dlcjIpOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl Pk9mZmVyZXJVQS0mZ3Q7QW5zd2VyZXI/VUE6ICZsdDttZWRpYSZndDs/PG86cD48L286cD48L3By ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+TXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IOKAnGFuc3dlcjLigJ0gd2ls bCB1cGRhdGUg4oCcYW5zd2VyMeKAnSBpbiBicm93c2VyIGFuZCBzdGFydGluZyBzZW5kaW5nL3Jl Y2VpdmluZyBtZWRpYSB0b3dhcmRzIGFuc3dlcjIgbWVkaWEgSVAgYW5kIHBvcnQuIENvdWxkIHlv dSBwbGVhc2UNCiBleHBsYWluIHRoZSBleHBlY3RlZCBiZWhhdmlvciBpbiBvZmZlcmVyIGJyb3dz ZXIgd2hldGhlciBpdCB1cGRhdGVzIHRoZSBtZWRpYSBzdHJlYW0gYmFzZWQgb24gdGhlIGxhc3Qg YW5zd2VyIG9yIG1peGVzIGJvdGggYW5zd2VyZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3M8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+UGFydGhhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+IHJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cnRjd2ViLWJv dW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkp1c3RpbiBVYmVydGk8YnI+DQo8 Yj5TZW50OjwvYj4gVGh1cnNkYXksIEZlYnJ1YXJ5IDA5LCAyMDEyIDI6MjcgQU08YnI+DQo8Yj5U bzo8L2I+IHJ0Y3dlYkBpZXRmLm9yZzsgcHVibGljLXdlYnJ0Y0B3My5vcmc8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gW3J0Y3dlYl0gTmV3IEpTRVAgZHJhZnQgcG9zdGVkPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm93IGF2YWlsYWJsZSBhdCA8YSBocmVmPSJo dHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LXViZXJ0aS1ydGN3ZWItanNlcC0wMS50eHQiPg0K aHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC11YmVydGktcnRjd2ViLWpzZXAtMDEudHh0PC9h PjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW5jbHVkZXMg Y2hhbmdlcyBiYXNlZCBvbiBpbXBsZW1lbnRhdGlvbiBmZWVkYmFjaywgYW5kIEkgYmVsaWV2ZSBp dCBhZGRyZXNzZXMgbW9zdCBvZiB0aGUgY29uY2VybnMgcmFpc2VkIGluIGxhc3Qgd2VlaydzIGlu dGVyaW0gbWVldGluZ3M6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4tIEluaXRpYWwgZG9jdW1lbnRhdGlvbiBwcm92aWRlZCBmb3IgZWFjaCBBUEkg Y2FsbCwgYW5kIHdoYXQgc3RhdGUgY2hhbmdlcyBpdCBjYXVzZXM8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gTW9yZSBleGFtcGxlcywgaW5jbHVk aW5nIGEgY29tcGxldGUgYmFzaWMgc2FtcGxlIGFwcGxpY2F0aW9uPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIFNpbXBsaWZpZWQgYXBwcm9hY2gg dG8gdHJpY2tsZSBjYW5kaWRhdGUgaGFuZGxpbmc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gUmVzb2x2ZWQgY29uY2VybnMgYWJvdXQgaG93IHRv IHNlcGFyYXRlIFNEUCBhdHRyaWJ1dGVzIGludG8gbWVkaWEgLyB0cmFuc3BvcnQ8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gUHJvdmlkZWQgZW5j YXBzdWxhdGlvbiBmb3IgU0RQIGJsb2JzIGFuZCBJQ0UgY2FuZGlkYXRlIGxpbmVzLCBpbiB0aGUg ZXZlbnQgd2Ugd2FudCB0byBjaGFuZ2UgZW5jb2RpbmdzIG9yIHByb3ZpZGUgaGVscGVyIGZ1bmN0 aW9ucyBmb3IgSlM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPi0gUHJvdmlkZWQgbWVjaGFuaXNtIGZvciBsaW1pdGluZyBjYW5kaWRhdGVzIHRvIFRV Uk4tb25seTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+LSBSZXNvbHZlZCBzZXZlcmFsIGltcGxlbWVudGF0aW9uIGlzc3VlczxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGhhdmUgbm90IHlldCBh ZGRyZXNzZWQgdGhlIG5vbi1vdmVybGFwcGluZyBjb2RlYyBjb25jZXJuIG1lbnRpb25lZCBpbiB0 aGUgaW50ZXJpbSBtZWV0aW5nLiBJIHRoaW5rIHRoZXJlIGFyZSB3YXlzIG9mIGhhbmRsaW5nIHRo aXMgZWl0aGVyIGluIHRoZSBhcHBsaWNhdGlvbiBvciB0aGUgaW1wbGVtZW50YXRpb24sIGJ1dCBJ IHdhbnRlZCB0byBnZXQgdGhpcyAtMDEgb3V0IGZpcnN0IGZvciBmZWVkYmFjay48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_387F9047F55E8C42850AD6B3A7A03C6C0E03F7E7inbamail01sonus_-- From snandaku@cisco.com Mon Feb 13 12:00: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 7D8B921F8710 for ; Mon, 13 Feb 2012 12:00:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hmI00vQbgx1 for ; Mon, 13 Feb 2012 12:00:59 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id A2E5021F86D5 for ; Mon, 13 Feb 2012 12:00:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=snandaku@cisco.com; l=307; q=dns/txt; s=iport; t=1329163251; x=1330372851; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=4C/OsHfYlMkgje3Au5xv+Pb1zW/+QT72D6IjPULDKcI=; b=RitDwRfDQzkFnaz/FjACuLSjsMOivQEhGIy0itWsmvM1u0yW5hvduzcC QX485E/U3We+u25OFBUu7t8Gi0dz7sxITDaYyYWJBmEHG2xYacAbRPJwc sd+/X9vql3yLtGvyrSg/bY5AQG5s9TjJZYfXoJgc4sDWM+RYNBaD32bkv M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABlrOU+tJV2Z/2dsb2JhbABDsBSBB4FzAQEEEgEdCk8CASoGGAYBVgEBBAEaGqUeAZZ7i00WJjcqAQIBhxhjBIhKn2s X-IronPort-AV: E=Sophos;i="4.73,413,1325462400"; d="scan'208";a="58577563" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 13 Feb 2012 20:00:51 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q1DK0pRC019643; Mon, 13 Feb 2012 20:00:51 GMT Received: from xmb-rcd-212.cisco.com ([72.163.62.219]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 Feb 2012 14:00:50 -0600 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: Mon, 13 Feb 2012 14:00:49 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ICE Candidate Gathering - Basic Thought Thread-Index: AczqYdJHoRsECR/dQ5OnP7UVl3gIfwAJ/RMQ References: <4F234B8B.4020204@jesup.org> <4F295660.3060001@jesup.org> <4F297011.1040507@jesup.org> From: "Suhas Nandakumar (snandaku)" To: , X-OriginalArrivalTime: 13 Feb 2012 20:00:50.0959 (UTC) FILETIME=[2F7699F0:01CCEA8A] Subject: [rtcweb] ICE Candidate Gathering - Basic Thought 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, 13 Feb 2012 20:00:59 -0000 I was wondering why should we link ICE candidate gathering procedures to call setup flow.=20 Can't this be done by browser periodically independent of RTCWeb call ? This may end up saving ton of time if the network topology doesn't change frequently. Is this a valid argument ? Cheers Suhas From juberti@google.com Mon Feb 13 19:30: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 E328021F8733 for ; Mon, 13 Feb 2012 19:30:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.689 X-Spam-Level: X-Spam-Status: No, score=-102.689 tagged_above=-999 required=5 tests=[AWL=0.287, 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 p7vEhq-UrYxD for ; Mon, 13 Feb 2012 19:30:26 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id A683721F8796 for ; Mon, 13 Feb 2012 19:30:19 -0800 (PST) Received: by iagf6 with SMTP id f6so6213840iag.31 for ; Mon, 13 Feb 2012 19:30:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=KiToacoOXbdKdyN8DjEYTpNQHg04fyPLNLDZxQJtxDo=; b=cPjPjbrwThfuucRP+XDBx6RMB7W7HgFSzjCe+iwnMM343Mn0boo/lAPkt7zgKfDlde tZzFTE4xUAI2vSMsfKIpfRprQqN/hdUGEx8mAY24tgRPKKG5qF1Xu+vahW/+qPZ4zDg9 yKEXLDCREp6kqJRSC30kiIiY9lE6fNjRwJF+o= Received: by 10.42.235.137 with SMTP id kg9mr25348759icb.47.1329190219375; Mon, 13 Feb 2012 19:30:19 -0800 (PST) Received: by 10.42.235.137 with SMTP id kg9mr25348751icb.47.1329190219255; Mon, 13 Feb 2012 19:30:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.85.132 with HTTP; Mon, 13 Feb 2012 19:29:59 -0800 (PST) In-Reply-To: <29CD92BB-6764-4B87-AA99-ADB4B9685059@iii.ca> References: <29CD92BB-6764-4B87-AA99-ADB4B9685059@iii.ca> From: Justin Uberti Date: Mon, 13 Feb 2012 22:29:59 -0500 Message-ID: To: Cullen Jennings Content-Type: multipart/alternative; boundary=20cf3026697adb8fd804b8e43690 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkfrwvPaumhR1OHyEk/1YInr7EWJTZEvV3KGHmK7geKyomUtpUszmGLK6aRMUTOCazqZ5aTv8aCZN1kglBPE6Vi0bdWwNoeueMG5REJdwL84V3kC8lXgE6i6O9EeiCyqVGKNTvpJ77F5Pg5e0s+TrcSepC6+A== Cc: rtcweb@ietf.org Subject: Re: [rtcweb] What parts of SDP need to changeable by the JS application 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, 14 Feb 2012 03:30:27 -0000 --20cf3026697adb8fd804b8e43690 Content-Type: text/plain; charset=UTF-8 We've had cases where we've needed to change the codec payload types, codec parameters (e.g. bitrate), and SRTP keys. For the rehydration use case, you really need to be able to supply just about everything though. On Mon, Feb 13, 2012 at 10:19 AM, Cullen Jennings wrote: > > I'd like to figure out what parts of the SDP that the JS App needs to be > able to change. > > The one clear example I have heard is removing a codec that the App does > not want to use. > > Are there others? > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --20cf3026697adb8fd804b8e43690 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable We've had cases where we've needed to change the codec payload type= s, codec parameters (e.g. bitrate), and SRTP keys.

--20cf3026697adb8fd804b8e43690-- From pravindran@sonusnet.com Mon Feb 13 22:24: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 13B9821E806B for ; Mon, 13 Feb 2012 22:24:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.018, 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 0RqYHqlR7sUU for ; Mon, 13 Feb 2012 22:24:47 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 5937521E8067 for ; Mon, 13 Feb 2012 22:24:47 -0800 (PST) Received: from sonusmail06.sonusnet.com (sonusmail06.sonusnet.com [10.128.32.156]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q1E6PVhk019396; Tue, 14 Feb 2012 01:25:31 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail06.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Feb 2012 01:24:43 -0500 Received: from INBA-HUB02.sonusnet.com ([10.70.51.87]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Feb 2012 11:54:51 +0530 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; Tue, 14 Feb 2012 11:54:50 +0530 From: "Ravindran, Parthasarathi" To: Justin Uberti , "rtcweb@ietf.org" , "public-webrtc@w3.org" Thread-Topic: Single offer with multiple answer handling in JSEP [was RE: [rtcweb] New JSEP draft posted] Thread-Index: AQHM6uFaIZmsOFGRck2Q3yR4wFD2TA== Date: Tue, 14 Feb 2012 06:24:49 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E03F8A4@inba-mail01.sonusnet.com> References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.70] Content-Type: multipart/alternative; boundary="_000_387F9047F55E8C42850AD6B3A7A03C6C0E03F8A4inbamail01sonus_" MIME-Version: 1.0 X-OriginalArrivalTime: 14 Feb 2012 06:24:51.0358 (UTC) FILETIME=[5BAE1BE0:01CCEAE1] Subject: Re: [rtcweb] Single offer with multiple answer handling in JSEP [was RE: New JSEP draft posted] 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, 14 Feb 2012 06:24:49 -0000 --_000_387F9047F55E8C42850AD6B3A7A03C6C0E03F8A4inbamail01sonus_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSnVzdGluLA0KDQpBZGRpbmcgdG8gbXkgZWFybGllciBtYWlsLCBJbiBjYXNlIGFuc3dlcjIg U0RQIGlzIHVwZGF0ZWQgaW4gb2ZmZXJlcjEgYnJvd3NlciB3aXRob3V0IG5vdGlmeWluZyBhbnN3 ZXJlcjEsIHRoZW4gYW5zd2VyMSB3aWxsIGNvbnRpbnVlIHRvIHRyYW5zbWl0IFJUUCB3aGljaCBt YXkgbm90IGJlIGRlc2lyZWQgYmVoYXZpb3IuIElNTywgd2UgbmVlZCB0byBkZWZpbmUgdGhpcyBi ZWhhdmlvciBjbGVhcmx5IGluIG9mZmVyZXIgc2lkZS4gU29tZSBvZiB0aGUgcG9zc2libGUgc29s dXRpb25zIGFyZQ0KDQoNCjEpICAgICAgb2ZmZXJlcjEgaGFzIHRvIHNlbmQgYXRsZWFzdCBSVENQ IEJZRSBwYWNrZXRzIHRvd2FyZHMgYW5zd2VyZXIxIHdoaWxlIGFjY2VwdGluZyB0aGUgYW5zd2Vy ZXIyIFNEUC4NCg0KMikgICAgICBUaHJvdyBjYWxsYmFjayB0byBjbGVhciBhbnN3ZXIxIFNEUCB0 b3dhcmRzIG9mZmVyZXJKUy4NCg0KUGxlYXNlIGxldCBtZSBrbm93IHlvdXIgb3BpbmlvbiBoZXJl Lg0KDQpUaGFua3MNClBhcnRoYQ0KDQpGcm9tOiBSYXZpbmRyYW4sIFBhcnRoYXNhcmF0aGkNClNl bnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDE0LCAyMDEyIDEyOjA3IEFNDQpUbzogJ0p1c3RpbiBVYmVy dGknOyBydGN3ZWJAaWV0Zi5vcmc7IHB1YmxpYy13ZWJydGNAdzMub3JnDQpTdWJqZWN0OiBTaW5n bGUgb2ZmZXIgd2l0aCBtdWx0aXBsZSBhbnN3ZXIgaGFuZGxpbmcgaW4gSlNFUCBbd2FzIFJFOiBb cnRjd2ViXSBOZXcgSlNFUCBkcmFmdCBwb3N0ZWRdDQoNCkhpIEp1c3RpbiwNCg0KSW4gdGhlIGRy YWZ0LCBpdCBpcyBub3Qgc3BlbGxlZCBvdXQgZXhwbGljaXRseSB3aGF0IGlzIHRoZSBleHBlY3Rl ZCBiZWhhdmlvciBpbiBvZmZlcmVyIGJyb3dzZXIgaW4gY2FzZSBtdWx0aXBsZSBhbnN3ZXIgaXMg cmVjZWl2ZWQgZm9yIHNpbmdsZSBvZmZlci4gT2ZmZXIvYW5zd2VyIGV4Y2hhbmdlIGluIG9mZmVy ZXIgaXMgYXMgZm9sbG93czoNCg0KDQpPZmZlcmVySlMtPk9mZmVyZXJVQTogdmFyIG9mZmVyID0g cGMuY3JlYXRlT2ZmZXIobnVsbCk7DQpPZmZlcmVySlMtPk9mZmVyZXJVQTogcGMuc2V0TG9jYWxE ZXNjcmlwdGlvbihTRFBfT0ZGRVIsIG9mZmVyKTsNCg0KT2ZmZXJlckpTLT5PZmZlcmVyVUE6ICBw Yy5zZXRSZW1vdGVEZXNjcmlwdGlvbihTRFBfQU5TV0VSLCBhbnN3ZXIxKTsNCg0KT2ZmZXJlclVB LT5BbnN3ZXJlcjFVQTogPG1lZGlhPg0KDQpPZmZlcmVySlMtPk9mZmVyZXJVQTogIHBjLnNldFJl bW90ZURlc2NyaXB0aW9uKFNEUF9BTlNXRVIsIGFuc3dlcjIpOw0KDQpPZmZlcmVyVUEtPkFuc3dl cmVyP1VBOiA8bWVkaWE+Pw0KDQpNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQg4oCcYW5zd2VyMuKA nSB3aWxsIHVwZGF0ZSDigJxhbnN3ZXIx4oCdIGluIGJyb3dzZXIgYW5kIHN0YXJ0aW5nIHNlbmRp bmcvcmVjZWl2aW5nIG1lZGlhIHRvd2FyZHMgYW5zd2VyMiBtZWRpYSBJUCBhbmQgcG9ydC4gQ291 bGQgeW91IHBsZWFzZSBleHBsYWluIHRoZSBleHBlY3RlZCBiZWhhdmlvciBpbiBvZmZlcmVyIGJy b3dzZXIgd2hldGhlciBpdCB1cGRhdGVzIHRoZSBtZWRpYSBzdHJlYW0gYmFzZWQgb24gdGhlIGxh c3QgYW5zd2VyIG9yIG1peGVzIGJvdGggYW5zd2VyZXIuDQoNClRoYW5rcw0KUGFydGhhDQoNCkZy b206IHJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9y Zz4gW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEp1c3RpbiBV YmVydGkNClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAwOSwgMjAxMiAyOjI3IEFNDQpUbzogcnRj d2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+OyBwdWJsaWMtd2VicnRjQHczLm9y ZzxtYWlsdG86cHVibGljLXdlYnJ0Y0B3My5vcmc+DQpTdWJqZWN0OiBbcnRjd2ViXSBOZXcgSlNF UCBkcmFmdCBwb3N0ZWQNCg0KTm93IGF2YWlsYWJsZSBhdCBodHRwOi8vd3d3LmlldGYub3JnL2lk L2RyYWZ0LXViZXJ0aS1ydGN3ZWItanNlcC0wMS50eHQNCg0KSW5jbHVkZXMgY2hhbmdlcyBiYXNl ZCBvbiBpbXBsZW1lbnRhdGlvbiBmZWVkYmFjaywgYW5kIEkgYmVsaWV2ZSBpdCBhZGRyZXNzZXMg bW9zdCBvZiB0aGUgY29uY2VybnMgcmFpc2VkIGluIGxhc3Qgd2VlaydzIGludGVyaW0gbWVldGlu Z3M6DQotIEluaXRpYWwgZG9jdW1lbnRhdGlvbiBwcm92aWRlZCBmb3IgZWFjaCBBUEkgY2FsbCwg YW5kIHdoYXQgc3RhdGUgY2hhbmdlcyBpdCBjYXVzZXMNCi0gTW9yZSBleGFtcGxlcywgaW5jbHVk aW5nIGEgY29tcGxldGUgYmFzaWMgc2FtcGxlIGFwcGxpY2F0aW9uDQotIFNpbXBsaWZpZWQgYXBw cm9hY2ggdG8gdHJpY2tsZSBjYW5kaWRhdGUgaGFuZGxpbmcNCi0gUmVzb2x2ZWQgY29uY2VybnMg YWJvdXQgaG93IHRvIHNlcGFyYXRlIFNEUCBhdHRyaWJ1dGVzIGludG8gbWVkaWEgLyB0cmFuc3Bv cnQNCi0gUHJvdmlkZWQgZW5jYXBzdWxhdGlvbiBmb3IgU0RQIGJsb2JzIGFuZCBJQ0UgY2FuZGlk YXRlIGxpbmVzLCBpbiB0aGUgZXZlbnQgd2Ugd2FudCB0byBjaGFuZ2UgZW5jb2RpbmdzIG9yIHBy b3ZpZGUgaGVscGVyIGZ1bmN0aW9ucyBmb3IgSlMNCi0gUHJvdmlkZWQgbWVjaGFuaXNtIGZvciBs aW1pdGluZyBjYW5kaWRhdGVzIHRvIFRVUk4tb25seQ0KLSBSZXNvbHZlZCBzZXZlcmFsIGltcGxl bWVudGF0aW9uIGlzc3Vlcw0KDQpJIGhhdmUgbm90IHlldCBhZGRyZXNzZWQgdGhlIG5vbi1vdmVy bGFwcGluZyBjb2RlYyBjb25jZXJuIG1lbnRpb25lZCBpbiB0aGUgaW50ZXJpbSBtZWV0aW5nLiBJ IHRoaW5rIHRoZXJlIGFyZSB3YXlzIG9mIGhhbmRsaW5nIHRoaXMgZWl0aGVyIGluIHRoZSBhcHBs aWNhdGlvbiBvciB0aGUgaW1wbGVtZW50YXRpb24sIGJ1dCBJIHdhbnRlZCB0byBnZXQgdGhpcyAt MDEgb3V0IGZpcnN0IGZvciBmZWVkYmFjay4NCg== --_000_387F9047F55E8C42850AD6B3A7A03C6C0E03F8A4inbamail01sonus_ 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 Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2lu OjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2 Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9 DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFy YWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJn aW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJ e21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZh bWlseToiQ291cmllciBOZXciO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6 IzFGNDk3RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9v biBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi QmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bh bi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjI0 MzYxMzQxNzsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6 MTk4NTEyNTAwOCA2NzY5ODcwNSA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2 NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7 bXNvLWxldmVsLXRleHQ6IiUxXCkiOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0Kb2wNCgl7 bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBKdXN0aW4sPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BZGRpbmcg dG8gbXkgZWFybGllciBtYWlsLCBJbiBjYXNlIGFuc3dlcjIgU0RQIGlzIHVwZGF0ZWQgaW4gb2Zm ZXJlcjEgYnJvd3NlciB3aXRob3V0IG5vdGlmeWluZyBhbnN3ZXJlcjEsIHRoZW4gYW5zd2VyMSB3 aWxsIGNvbnRpbnVlIHRvIHRyYW5zbWl0IFJUUCB3aGljaA0KIG1heSBub3QgYmUgZGVzaXJlZCBi ZWhhdmlvci4gSU1PLCB3ZSBuZWVkIHRvIGRlZmluZSB0aGlzIGJlaGF2aW9yIGNsZWFybHkgaW4g b2ZmZXJlciBzaWRlLiBTb21lIG9mIHRoZSBwb3NzaWJsZSBzb2x1dGlvbnMgYXJlPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0 OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+MSk8 c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZd PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5vZmZlcmVyMSBoYXMg dG8gc2VuZCBhdGxlYXN0IFJUQ1AgQllFIHBhY2tldHMgdG93YXJkcyBhbnN3ZXJlcjEgd2hpbGUg YWNjZXB0aW5nIHRoZSBhbnN3ZXJlcjIgU0RQLiZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47 bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdu b3JlIj4yKTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48 IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRocm93 IGNhbGxiYWNrIHRvIGNsZWFyIGFuc3dlcjEgU0RQIHRvd2FyZHMgb2ZmZXJlckpTLjxicj4NCjxi cj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5QbGVhc2UgbGV0IG1lIGtub3cgeW91 ciBvcGluaW9uIGhlcmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+UGFydGhhDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz LjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4gUmF2aW5kcmFuLCBQYXJ0aGFzYXJhdGhpDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwg RmVicnVhcnkgMTQsIDIwMTIgMTI6MDcgQU08YnI+DQo8Yj5Ubzo8L2I+ICdKdXN0aW4gVWJlcnRp JzsgcnRjd2ViQGlldGYub3JnOyBwdWJsaWMtd2VicnRjQHczLm9yZzxicj4NCjxiPlN1YmplY3Q6 PC9iPiBTaW5nbGUgb2ZmZXIgd2l0aCBtdWx0aXBsZSBhbnN3ZXIgaGFuZGxpbmcgaW4gSlNFUCBb d2FzIFJFOiBbcnRjd2ViXSBOZXcgSlNFUCBkcmFmdCBwb3N0ZWRdPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkhpIEp1c3Rpbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkluIHRoZSBkcmFmdCwgaXQgaXMg bm90IHNwZWxsZWQgb3V0IGV4cGxpY2l0bHkgd2hhdCBpcyB0aGUgZXhwZWN0ZWQgYmVoYXZpb3Ig aW4gb2ZmZXJlciBicm93c2VyIGluIGNhc2UgbXVsdGlwbGUgYW5zd2VyIGlzIHJlY2VpdmVkIGZv ciBzaW5nbGUgb2ZmZXIuIE9mZmVyL2Fuc3dlcg0KIGV4Y2hhbmdlIGluIG9mZmVyZXIgaXMgYXMg Zm9sbG93czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHByZT5PZmZlcmVySlMtJmd0O09mZmVyZXJVQTogdmFyIG9mZmVyID0gcGMu Y3JlYXRlT2ZmZXIobnVsbCk7PG86cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij5PZmZlcmVySlMtJmd0O09mZmVyZXJVQTogcGMuc2V0TG9jYWxEZXNjcmlwdGlv bihTRFBfT0ZGRVIsIG9mZmVyKTs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlPk9mZmVyZXJK Uy0mZ3Q7T2ZmZXJlclVBOiZuYnNwOyBwYy5zZXRSZW1vdGVEZXNjcmlwdGlvbihTRFBfQU5TV0VS LCBhbnN3ZXIxKTs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5PZmZlcmVyVUEtJmd0O0Fuc3dlcmVy MVVBOiAmbHQ7bWVkaWEmZ3Q7PG86cD48L286cD48L3ByZT4NCjxwcmU+T2ZmZXJlckpTLSZndDtP ZmZlcmVyVUE6Jm5ic3A7IHBjLnNldFJlbW90ZURlc2NyaXB0aW9uKFNEUF9BTlNXRVIsIGFuc3dl cjIpOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk9mZmVyZXJVQS0mZ3Q7QW5zd2VyZXI/VUE6ICZs dDttZWRpYSZndDs/PG86cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TXkgdW5kZXJzdGFuZGlu ZyBpcyB0aGF0IOKAnGFuc3dlcjLigJ0gd2lsbCB1cGRhdGUg4oCcYW5zd2VyMeKAnSBpbiBicm93 c2VyIGFuZCBzdGFydGluZyBzZW5kaW5nL3JlY2VpdmluZyBtZWRpYSB0b3dhcmRzIGFuc3dlcjIg bWVkaWEgSVAgYW5kIHBvcnQuIENvdWxkIHlvdSBwbGVhc2UNCiBleHBsYWluIHRoZSBleHBlY3Rl ZCBiZWhhdmlvciBpbiBvZmZlcmVyIGJyb3dzZXIgd2hldGhlciBpdCB1cGRhdGVzIHRoZSBtZWRp YSBzdHJlYW0gYmFzZWQgb24gdGhlIGxhc3QgYW5zd2VyIG9yIG1peGVzIGJvdGggYW5zd2VyZXIu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5UaGFua3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UGFydGhhPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFk ZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+DQo8YSBocmVmPSJtYWls dG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmciPnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnPC9hPiBb PGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86cnRjd2ViLWJv dW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5KdXN0aW4gVWJlcnRpPGJy Pg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBGZWJydWFyeSAwOSwgMjAxMiAyOjI3IEFNPGJyPg0K PGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIj5ydGN3ZWJAaWV0Zi5v cmc8L2E+OyA8YSBocmVmPSJtYWlsdG86cHVibGljLXdlYnJ0Y0B3My5vcmciPg0KcHVibGljLXdl YnJ0Y0B3My5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtydGN3ZWJdIE5ldyBKU0VQIGRy YWZ0IHBvc3RlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk5vdyBhdmFpbGFibGUgYXQgPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC11 YmVydGktcnRjd2ViLWpzZXAtMDEudHh0Ij4NCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQt dWJlcnRpLXJ0Y3dlYi1qc2VwLTAxLnR4dDwvYT48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkluY2x1ZGVzIGNoYW5nZXMgYmFzZWQgb24gaW1wbGVtZW50YXRp b24gZmVlZGJhY2ssIGFuZCBJIGJlbGlldmUgaXQgYWRkcmVzc2VzIG1vc3Qgb2YgdGhlIGNvbmNl cm5zIHJhaXNlZCBpbiBsYXN0IHdlZWsncyBpbnRlcmltIG1lZXRpbmdzOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBJbml0aWFsIGRvY3VtZW50 YXRpb24gcHJvdmlkZWQgZm9yIGVhY2ggQVBJIGNhbGwsIGFuZCB3aGF0IHN0YXRlIGNoYW5nZXMg aXQgY2F1c2VzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4tIE1vcmUgZXhhbXBsZXMsIGluY2x1ZGluZyBhIGNvbXBsZXRlIGJhc2ljIHNhbXBsZSBh cHBsaWNhdGlvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+LSBTaW1wbGlmaWVkIGFwcHJvYWNoIHRvIHRyaWNrbGUgY2FuZGlkYXRlIGhhbmRsaW5n PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIFJl c29sdmVkIGNvbmNlcm5zIGFib3V0IGhvdyB0byBzZXBhcmF0ZSBTRFAgYXR0cmlidXRlcyBpbnRv IG1lZGlhIC8gdHJhbnNwb3J0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4tIFByb3ZpZGVkIGVuY2Fwc3VsYXRpb24gZm9yIFNEUCBibG9icyBhbmQg SUNFIGNhbmRpZGF0ZSBsaW5lcywgaW4gdGhlIGV2ZW50IHdlIHdhbnQgdG8gY2hhbmdlIGVuY29k aW5ncyBvciBwcm92aWRlIGhlbHBlciBmdW5jdGlvbnMgZm9yIEpTPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIFByb3ZpZGVkIG1lY2hhbmlzbSBm b3IgbGltaXRpbmcgY2FuZGlkYXRlcyB0byBUVVJOLW9ubHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gUmVzb2x2ZWQgc2V2ZXJhbCBpbXBsZW1l bnRhdGlvbiBpc3N1ZXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SSBoYXZlIG5vdCB5ZXQgYWRkcmVzc2VkIHRoZSBub24tb3ZlcmxhcHBpbmcg Y29kZWMgY29uY2VybiBtZW50aW9uZWQgaW4gdGhlIGludGVyaW0gbWVldGluZy4gSSB0aGluayB0 aGVyZSBhcmUgd2F5cyBvZiBoYW5kbGluZyB0aGlzIGVpdGhlciBpbiB0aGUgYXBwbGljYXRpb24g b3IgdGhlIGltcGxlbWVudGF0aW9uLCBidXQgSSB3YW50ZWQgdG8gZ2V0IHRoaXMgLTAxIG91dCBm aXJzdCBmb3IgZmVlZGJhY2suPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_387F9047F55E8C42850AD6B3A7A03C6C0E03F8A4inbamail01sonus_-- From harald@alvestrand.no Tue Feb 14 01:15: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 79CF621F878B for ; Tue, 14 Feb 2012 01:15:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.492 X-Spam-Level: X-Spam-Status: No, score=-110.492 tagged_above=-999 required=5 tests=[AWL=0.107, 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 ojV0H+OUaTZ1 for ; Tue, 14 Feb 2012 01:15:42 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 2F67C21F8750 for ; Tue, 14 Feb 2012 01:15:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6E09539E113; Tue, 14 Feb 2012 10:15:41 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Y3ZS9UUHfqh; Tue, 14 Feb 2012 10:15:40 +0100 (CET) Received: from hta-dell.lul.corp.google.com (unknown [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 6763339E0FD; Tue, 14 Feb 2012 10:15:40 +0100 (CET) Message-ID: <4F3A263B.7040806@alvestrand.no> Date: Tue, 14 Feb 2012 10:15:39 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.26) Gecko/20120131 Thunderbird/3.1.18 MIME-Version: 1.0 To: Cullen Jennings References: <29CD92BB-6764-4B87-AA99-ADB4B9685059@iii.ca> In-Reply-To: <29CD92BB-6764-4B87-AA99-ADB4B9685059@iii.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] What parts of SDP need to changeable by the JS application 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, 14 Feb 2012 09:15:43 -0000 On 02/13/2012 04:19 PM, Cullen Jennings wrote: > I'd like to figure out what parts of the SDP that the JS App needs to be able to change. > > The one clear example I have heard is removing a codec that the App does not want to use. > > Are there others? Off the top of my head, stuff that has been mentioned that seems sensible to me: 1) If candidates become available after the CreateOffer / CreateAnswer call, but before the SDP is sent to the peer, the JS needs to add them to the SDP. 2) If the application wants to not use BUNDLE for some reason, the JS needs to disable BUNDLE 3) Reducing offered resolution for video to the needs of the application (if draft-ietf-mmusic-sdp-media-capabilities is supported) 4) Reducing the b= (bandwidth) value if the application knows of a bandwidth constraint that the browser can't know about Apart from that, I think it's hard to say without a concise list of the SDP features that the browser has to support; we haven't gotten around to that one yet. (Is there an existing document that this would fit into, or a clear vision that we need a separate document for this one? Should we ask for contributions, or pick an editor?) Harald From harald@alvestrand.no Tue Feb 14 01:23: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 4FEC321F8730 for ; Tue, 14 Feb 2012 01:23:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.497 X-Spam-Level: X-Spam-Status: No, score=-110.497 tagged_above=-999 required=5 tests=[AWL=0.102, 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 1Mx0tZfw0vEm for ; Tue, 14 Feb 2012 01:23:04 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id BA4E921F872A for ; Tue, 14 Feb 2012 01:23:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0072639E113; Tue, 14 Feb 2012 10:23:04 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Li1PMnsHnNB; Tue, 14 Feb 2012 10:23:03 +0100 (CET) Received: from hta-dell.lul.corp.google.com (unknown [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 83FF239E0FD; Tue, 14 Feb 2012 10:23:03 +0100 (CET) Message-ID: <4F3A27F6.40203@alvestrand.no> Date: Tue, 14 Feb 2012 10:23:02 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.26) Gecko/20120131 Thunderbird/3.1.18 MIME-Version: 1.0 To: "Suhas Nandakumar (snandaku)" References: <4F234B8B.4020204@jesup.org> <4F295660.3060001@jesup.org> <4F297011.1040507@jesup.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org, public-webrtc@w3.org Subject: Re: [rtcweb] ICE Candidate Gathering - Basic Thought 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, 14 Feb 2012 09:23:05 -0000 On 02/13/2012 09:00 PM, Suhas Nandakumar (snandaku) wrote: > I was wondering why should we link ICE candidate gathering procedures to > call setup flow. > Can't this be done by browser periodically independent of RTCWeb call ? > > This may end up saving ton of time if the network topology doesn't > change frequently. > > Is this a valid argument ? the chief problem with that thought is that with current APIs, the browser does not know which STUN/TURN server to use before the PeerConnection is created (it's an init parameter). If we want this separation, we would have to create some object (PeerConnectionFactory?) that would take the STUN/TURN server name as parameters, gather the candidates and generate a PeerConnection object with these candidates when required. This may be a Good Thing for other reasons (the rehydration case - reestablishing a connection when the user does "reload"), but does complicate the simple case. Harald From pravindran@sonusnet.com Tue Feb 14 01:44: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 A3BC421F866D for ; Tue, 14 Feb 2012 01:44:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 DOIxKhXal7+t for ; Tue, 14 Feb 2012 01:44:48 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 0077B21F8633 for ; Tue, 14 Feb 2012 01:44:47 -0800 (PST) Received: from sonusmail06.sonusnet.com (sonusmail06.sonusnet.com [10.128.32.156]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q1E9jVvg019943; Tue, 14 Feb 2012 04:45:31 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail06.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Feb 2012 04:44:43 -0500 Received: from INBA-HUB02.sonusnet.com ([10.70.51.87]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Feb 2012 15:14:51 +0530 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; Tue, 14 Feb 2012 15:14:50 +0530 From: "Ravindran, Parthasarathi" To: Harald Alvestrand , Cullen Jennings Thread-Topic: [rtcweb] What parts of SDP need to changeable by the JS application Thread-Index: AQHM6vlGxk6bacHYgUSl+70iDCA6k5Y8Ie5w Date: Tue, 14 Feb 2012 09:44:49 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E03F98C@inba-mail01.sonusnet.com> References: <29CD92BB-6764-4B87-AA99-ADB4B9685059@iii.ca> <4F3A263B.7040806@alvestrand.no> In-Reply-To: <4F3A263B.7040806@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.70] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 14 Feb 2012 09:44:51.0498 (UTC) FILETIME=[4C5228A0:01CCEAFD] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] What parts of SDP need to changeable by the JS application 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, 14 Feb 2012 09:44:48 -0000 JS application shall also change few other SDP attributes like:=20 1) "direction" attribute by which control the mediaflow. For example: chang= ing from "sendrecv" to "sendonly" or "inactive". 2) "ptime" attribute in case of audio codecs by which packetization time sh= all be changed. (Here, browser codec support is required). Just my 2 cents. Thanks Partha >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of Harald Alvestrand >Sent: Tuesday, February 14, 2012 2:46 PM >To: Cullen Jennings >Cc: rtcweb@ietf.org >Subject: Re: [rtcweb] What parts of SDP need to changeable by the JS >application > >On 02/13/2012 04:19 PM, Cullen Jennings wrote: >> I'd like to figure out what parts of the SDP that the JS App needs to >be able to change. >> >> The one clear example I have heard is removing a codec that the App >does not want to use. >> >> Are there others? >Off the top of my head, stuff that has been mentioned that seems >sensible to me: > >1) If candidates become available after the CreateOffer / CreateAnswer >call, but before the SDP is sent to the peer, the JS needs to add them >to the SDP. > >2) If the application wants to not use BUNDLE for some reason, the JS >needs to disable BUNDLE > >3) Reducing offered resolution for video to the needs of the application >(if draft-ietf-mmusic-sdp-media-capabilities is supported) > >4) Reducing the b=3D (bandwidth) value if the application knows of a >bandwidth constraint that the browser can't know about > >Apart from that, I think it's hard to say without a concise list of the >SDP features that the browser has to support; we haven't gotten around >to that one yet. >(Is there an existing document that this would fit into, or a clear >vision that we need a separate document for this one? Should we ask for >contributions, or pick an editor?) > > Harald > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From christer.holmberg@ericsson.com Tue Feb 14 04:27: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 0A0EB21F87A8 for ; Tue, 14 Feb 2012 04:27:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.319 X-Spam-Level: X-Spam-Status: No, score=-9.319 tagged_above=-999 required=5 tests=[AWL=1.280, 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 EbaSC2STi1FK for ; Tue, 14 Feb 2012 04:27:09 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id C2AC421F86E5 for ; Tue, 14 Feb 2012 04:27:08 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-0f-4f3a531bcf4c Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 98.53.27041.B135A3F4; Tue, 14 Feb 2012 13:27:07 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Tue, 14 Feb 2012 13:27:07 +0100 From: Christer Holmberg To: Cullen Jennings , "rtcweb@ietf.org" Date: Tue, 14 Feb 2012 13:27:07 +0100 Thread-Topic: [rtcweb] What parts of SDP need to changeable by the JS application Thread-Index: AczqYtsra4t/28LaStuQDIwR8R31ugAsOIGA Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3D87D9E1@ESESSCMS0356.eemea.ericsson.se> References: <29CD92BB-6764-4B87-AA99-ADB4B9685059@iii.ca> In-Reply-To: <29CD92BB-6764-4B87-AA99-ADB4B9685059@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-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] What parts of SDP need to changeable by the JS application 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, 14 Feb 2012 12:27:10 -0000 Hi, A related question is: if the JS App changes some information, does it need= to inform the browser about it? OR, should the JS App only be allowed to change information which the brows= er does not need to be informed about? Regards, Christer =20 -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Cullen Jennings Sent: 13. helmikuuta 2012 17:19 To: rtcweb@ietf.org Subject: [rtcweb] What parts of SDP need to changeable by the JS applicatio= n I'd like to figure out what parts of the SDP that the JS App needs to be ab= le to change.=20 The one clear example I have heard is removing a codec that the App does no= t want to use. Are there others?=20 _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From Markus.Isomaki@nokia.com Tue Feb 14 04:33: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 2B1AC21F87B1 for ; Tue, 14 Feb 2012 04:33:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tc8zTT1bDQgS for ; Tue, 14 Feb 2012 04:33:26 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 0188821F87BA for ; Tue, 14 Feb 2012 04:33:25 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (in-mx.nokia.com [10.160.244.31]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q1ECXE5M026989; Tue, 14 Feb 2012 14:33:21 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.61]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Feb 2012 14:33:18 +0200 Received: from 008-AM1MPN1-041.mgdnok.nokia.com ([169.254.1.220]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0355.003; Tue, 14 Feb 2012 13:33:18 +0100 From: To: , , Thread-Topic: [rtcweb] What parts of SDP need to changeable by the JS application Thread-Index: AQHM6mLfHGEadbIScEylrjlV3TEibZY8QmSAgAAR2QA= Date: Tue, 14 Feb 2012 12:33:17 +0000 Message-ID: References: <29CD92BB-6764-4B87-AA99-ADB4B9685059@iii.ca> <7F2072F1E0DE894DA4B517B93C6A05852C3D87D9E1@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3D87D9E1@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.21.81.125] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 14 Feb 2012 12:33:18.0993 (UTC) FILETIME=[D4DB8010:01CCEB14] X-Nokia-AV: Clean Subject: Re: [rtcweb] What parts of SDP need to changeable by the JS application 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, 14 Feb 2012 12:33:27 -0000 Hi, I suppose there is no-one to control what is "allowed". So, anything is all= owed as long as it "works". And I guess it works as long as the service pro= vider thinks it does. Right? Markus >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of ext Christer Holmberg >Sent: 14 February, 2012 14:27 >To: Cullen Jennings; rtcweb@ietf.org >Subject: Re: [rtcweb] What parts of SDP need to changeable by the JS >application > > >Hi, > >A related question is: if the JS App changes some information, does it nee= d to >inform the browser about it? > >OR, should the JS App only be allowed to change information which the >browser does not need to be informed about? > >Regards, > >Christer > > > > > > > >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of Cullen Jennings >Sent: 13. helmikuuta 2012 17:19 >To: rtcweb@ietf.org >Subject: [rtcweb] What parts of SDP need to changeable by the JS applicati= on > > >I'd like to figure out what parts of the SDP that the JS App needs to be a= ble to >change. > >The one clear example I have heard is removing a codec that the App does n= ot >want to use. > >Are there others? >_______________________________________________ >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 christer.holmberg@ericsson.com Tue Feb 14 04:55: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 4E24F21F87AB for ; Tue, 14 Feb 2012 04:55:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.377 X-Spam-Level: X-Spam-Status: No, score=-9.377 tagged_above=-999 required=5 tests=[AWL=1.222, 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 Llud3Jr-FQii for ; Tue, 14 Feb 2012 04:55:37 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 7254A21F87C3 for ; Tue, 14 Feb 2012 04:55:36 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-6d-4f3a59c7cfb2 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 6B.7E.01970.7C95A3F4; Tue, 14 Feb 2012 13:55:35 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Tue, 14 Feb 2012 13:55:35 +0100 From: Christer Holmberg To: "Markus.Isomaki@nokia.com" , "fluffy@iii.ca" , "rtcweb@ietf.org" Date: Tue, 14 Feb 2012 13:55:34 +0100 Thread-Topic: [rtcweb] What parts of SDP need to changeable by the JS application Thread-Index: AQHM6mLfHGEadbIScEylrjlV3TEibZY8QmSAgAAR2QCAAAaZMA== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3D87DA31@ESESSCMS0356.eemea.ericsson.se> References: <29CD92BB-6764-4B87-AA99-ADB4B9685059@iii.ca> <7F2072F1E0DE894DA4B517B93C6A05852C3D87D9E1@ESESSCMS0356.eemea.ericsson.se> 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 X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] What parts of SDP need to changeable by the JS application 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, 14 Feb 2012 12:55:38 -0000 Hi, Then the question is: should the API support informing the browser what has= been changed, or do we assume that everything "will be taken care of" once= the answer is provided? Regards, Christer =20 -----Original Message----- From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com]=20 Sent: 14. helmikuuta 2012 14:33 To: Christer Holmberg; fluffy@iii.ca; rtcweb@ietf.org Subject: RE: [rtcweb] What parts of SDP need to changeable by the JS applic= ation Hi, I suppose there is no-one to control what is "allowed". So, anything is all= owed as long as it "works". And I guess it works as long as the service pro= vider thinks it does. Right? Markus >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On=20 >Behalf Of ext Christer Holmberg >Sent: 14 February, 2012 14:27 >To: Cullen Jennings; rtcweb@ietf.org >Subject: Re: [rtcweb] What parts of SDP need to changeable by the JS=20 >application > > >Hi, > >A related question is: if the JS App changes some information, does it=20 >need to inform the browser about it? > >OR, should the JS App only be allowed to change information which the=20 >browser does not need to be informed about? > >Regards, > >Christer > > > > > > > >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On=20 >Behalf Of Cullen Jennings >Sent: 13. helmikuuta 2012 17:19 >To: rtcweb@ietf.org >Subject: [rtcweb] What parts of SDP need to changeable by the JS=20 >application > > >I'd like to figure out what parts of the SDP that the JS App needs to=20 >be able to change. > >The one clear example I have heard is removing a codec that the App=20 >does not want to use. > >Are there others? >_______________________________________________ >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 Feb 14 05:42: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 CCBB421F876C for ; Tue, 14 Feb 2012 05:42:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.120, 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 iGk6WgvQUsPD for ; Tue, 14 Feb 2012 05:42:17 -0800 (PST) Received: from relay-out1.dc.genesyslab.com (relay-out1.dc.genesyslab.com [198.49.180.220]) by ietfa.amsl.com (Postfix) with ESMTP id 0E72921F8766 for ; Tue, 14 Feb 2012 05:42:17 -0800 (PST) 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 q1EDgEAD014252; Tue, 14 Feb 2012 05:42:14 -0800 (PST) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Feb 2012 05:42:14 -0800 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_01CCEB1E.7622A88E" Date: Tue, 14 Feb 2012 05:41:40 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] What parts of SDP need to changeable by the JSapplication Thread-Index: AczqyQFbAhDhPB5EQe+dQBPT1lzxOwAVPqXw References: <29CD92BB-6764-4B87-AA99-ADB4B9685059@iii.ca> From: "Jim Barnett" To: "Justin Uberti" , "Cullen Jennings" X-OriginalArrivalTime: 14 Feb 2012 13:42:14.0834 (UTC) FILETIME=[7602C120:01CCEB1E] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] What parts of SDP need to changeable by the JSapplication 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, 14 Feb 2012 13:42:17 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCEB1E.7622A88E Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW4gdGhlIHJlaHlkcmF0aW9uIGNhc2UsIG11Y2ggb2Ygd2hhdCB0aGUgSlMgaXMgc3VwcGx5aW5n IGFyZSB2YWx1ZXMgdGhhdCB0aGUgYnJvd3NlciBpbml0aWFsbHkgZ2VuZXJhdGVkIChidXQgbG9z dCBvbiBwYWdlIHJlbG9hZCksIHNvIGl04oCZcyBub3QgcmVhbGx5IF9jaGFuZ2luZ18gdGhvc2Ug dmFsdWVzLiAgVGhlIHVuZGVybHlpbmcgcXVlc3Rpb24gaXM6IHdoaWNoIHBhcnRzIG9mIHRoZSBT RFAgY2FuIHRoZSBKUyBjaGFuZ2UgdG8gc29tZXRoaW5nIG90aGVyIHRoYW4gd2hhdCB0aGUgYnJv d3NlciBpbml0aWFsbHkgcHJvdmlkZWQ/IA0KDQogDQoNCi0gICAgICAgICAgSmltDQoNCiANCg0K RnJvbTogcnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIEp1c3RpbiBVYmVydGkNClNlbnQ6IE1vbmRheSwgRmVicnVhcnkg MTMsIDIwMTIgMTA6MzAgUE0NClRvOiBDdWxsZW4gSmVubmluZ3MNCkNjOiBydGN3ZWJAaWV0Zi5v cmcNClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBXaGF0IHBhcnRzIG9mIFNEUCBuZWVkIHRvIGNoYW5n ZWFibGUgYnkgdGhlIEpTYXBwbGljYXRpb24NCg0KIA0KDQpXZSd2ZSBoYWQgY2FzZXMgd2hlcmUg d2UndmUgbmVlZGVkIHRvIGNoYW5nZSB0aGUgY29kZWMgcGF5bG9hZCB0eXBlcywgY29kZWMgcGFy YW1ldGVycyAoZS5nLiBiaXRyYXRlKSwgYW5kIFNSVFAga2V5cy4NCg0KIA0KDQpGb3IgdGhlIHJl aHlkcmF0aW9uIHVzZSBjYXNlLCB5b3UgcmVhbGx5IG5lZWQgdG8gYmUgYWJsZSB0byBzdXBwbHkg anVzdCBhYm91dCBldmVyeXRoaW5nIHRob3VnaC4NCg0KT24gTW9uLCBGZWIgMTMsIDIwMTIgYXQg MTA6MTkgQU0sIEN1bGxlbiBKZW5uaW5ncyA8Zmx1ZmZ5QGlpaS5jYT4gd3JvdGU6DQoNCg0KSSdk IGxpa2UgdG8gZmlndXJlIG91dCB3aGF0IHBhcnRzIG9mIHRoZSBTRFAgdGhhdCB0aGUgSlMgQXBw IG5lZWRzIHRvIGJlIGFibGUgdG8gY2hhbmdlLg0KDQpUaGUgb25lIGNsZWFyIGV4YW1wbGUgSSBo YXZlIGhlYXJkIGlzIHJlbW92aW5nIGEgY29kZWMgdGhhdCB0aGUgQXBwIGRvZXMgbm90IHdhbnQg dG8gdXNlLg0KDQpBcmUgdGhlcmUgb3RoZXJzPw0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCnJ0Y3dlYkBpZXRmLm9y Zw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCg0KIA0KDQo= ------_=_NextPart_001_01CCEB1E.7622A88E Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDggMyA0O30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6Ik1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4 IDMgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiXEBNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAzIDQ7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywg c3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs aW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlz dFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0 Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTow aW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNw YW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlu O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZp bml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTIxMTgzOTQ2NDsNCgltc28tbGlz dC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTExOTE5MDM2OTAgLTIwNzQ4 NjA5MzAgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2 ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFy dC1hdDozOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseToiTVMgTWluY2hvIjsNCgltc28t YmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpvbA0KCXttYXJnaW4tYm90dG9t OjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9RU4t VVMgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5JbiB0aGUgcmVoeWRyYXRpb24gY2Fz ZSwgbXVjaCBvZiB3aGF0IHRoZSBKUyBpcyBzdXBwbHlpbmcgYXJlIHZhbHVlcyB0aGF0IHRoZSBi cm93c2VyIGluaXRpYWxseSBnZW5lcmF0ZWQgKGJ1dCBsb3N0IG9uIHBhZ2UgcmVsb2FkKSwgc28g aXTigJlzIG5vdCByZWFsbHkgXzxpPmNoYW5naW5nPC9pPl8gdGhvc2UgdmFsdWVzLsKgIFRoZSB1 bmRlcmx5aW5nIHF1ZXN0aW9uIGlzOiB3aGljaCBwYXJ0cyBvZiB0aGUgU0RQIGNhbiB0aGUgSlMg Y2hhbmdlIHRvIHNvbWV0aGluZyBvdGhlciB0aGFuIHdoYXQgdGhlIGJyb3dzZXIgaW5pdGlhbGx5 IHByb3ZpZGVkPyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b0xpc3RQYXJhZ3JhcGggc3R5bGU9J3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZl bDEgbGZvMSc+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48c3Bh biBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz4tPHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVz IE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz5KaW08bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXYgc3R5bGU9 J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNh bnMtc2VyaWYiJz4gcnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpydGN3ZWItYm91bmNl c0BpZXRmLm9yZ10gPGI+T24gQmVoYWxmIE9mIDwvYj5KdXN0aW4gVWJlcnRpPGJyPjxiPlNlbnQ6 PC9iPiBNb25kYXksIEZlYnJ1YXJ5IDEzLCAyMDEyIDEwOjMwIFBNPGJyPjxiPlRvOjwvYj4gQ3Vs bGVuIEplbm5pbmdzPGJyPjxiPkNjOjwvYj4gcnRjd2ViQGlldGYub3JnPGJyPjxiPlN1YmplY3Q6 PC9iPiBSZTogW3J0Y3dlYl0gV2hhdCBwYXJ0cyBvZiBTRFAgbmVlZCB0byBjaGFuZ2VhYmxlIGJ5 IHRoZSBKU2FwcGxpY2F0aW9uPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+V2UndmUgaGFk IGNhc2VzIHdoZXJlIHdlJ3ZlIG5lZWRlZCB0byBjaGFuZ2UgdGhlIGNvZGVjIHBheWxvYWQgdHlw ZXMsIGNvZGVjIHBhcmFtZXRlcnMgKGUuZy4gYml0cmF0ZSksIGFuZCBTUlRQIGtleXMuPG86cD48 L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz5G b3IgdGhlIHJlaHlkcmF0aW9uIHVzZSBjYXNlLCB5b3UgcmVhbGx5IG5lZWQgdG8gYmUgYWJsZSB0 byBzdXBwbHkganVzdCBhYm91dCBldmVyeXRoaW5nIHRob3VnaC48bzpwPjwvbzpwPjwvcD48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD5PbiBNb24sIEZlYiAxMywgMjAxMiBhdCAxMDoxOSBBTSwgQ3Vs bGVuIEplbm5pbmdzICZsdDs8YSBocmVmPSJtYWlsdG86Zmx1ZmZ5QGlpaS5jYSI+Zmx1ZmZ5QGlp aS5jYTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48YnI+ SSdkIGxpa2UgdG8gZmlndXJlIG91dCB3aGF0IHBhcnRzIG9mIHRoZSBTRFAgdGhhdCB0aGUgSlMg QXBwIG5lZWRzIHRvIGJlIGFibGUgdG8gY2hhbmdlLjxicj48YnI+VGhlIG9uZSBjbGVhciBleGFt cGxlIEkgaGF2ZSBoZWFyZCBpcyByZW1vdmluZyBhIGNvZGVjIHRoYXQgdGhlIEFwcCBkb2VzIG5v dCB3YW50IHRvIHVzZS48YnI+PGJyPkFyZSB0aGVyZSBvdGhlcnM/PGJyPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPnJ0Y3dlYiBtYWlsaW5nIGxpc3Q8 YnI+PGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+cnRjd2ViQGlldGYub3JnPC9hPjxi cj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYiIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRj d2ViPC9hPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNw OzwvbzpwPjwvcD48L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1sPg== ------_=_NextPart_001_01CCEB1E.7622A88E-- From Jim.Barnett@genesyslab.com Tue Feb 14 05:43: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 AD4CE21F877A for ; Tue, 14 Feb 2012 05:43:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 YYLNFMQ5OxHw for ; Tue, 14 Feb 2012 05:43:53 -0800 (PST) Received: from relay-out1.dc.genesyslab.com (relay-out1.dc.genesyslab.com [198.49.180.220]) by ietfa.amsl.com (Postfix) with ESMTP id 987D321F876C for ; Tue, 14 Feb 2012 05:43:53 -0800 (PST) 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 q1EDhjND014449; Tue, 14 Feb 2012 05:43:45 -0800 (PST) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Feb 2012 05:43:46 -0800 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, 14 Feb 2012 05:43:12 -0800 Message-ID: In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3D87D9E1@ESESSCMS0356.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] What parts of SDP need to changeable by the JS application Thread-Index: AczqYtsra4t/28LaStuQDIwR8R31ugAsOIGAAAKp5XA= References: <29CD92BB-6764-4B87-AA99-ADB4B9685059@iii.ca> <7F2072F1E0DE894DA4B517B93C6A05852C3D87D9E1@ESESSCMS0356.eemea.ericsson.se> From: "Jim Barnett" To: "Christer Holmberg" , "Cullen Jennings" , X-OriginalArrivalTime: 14 Feb 2012 13:43:46.0052 (UTC) FILETIME=[AC618440:01CCEB1E] Subject: Re: [rtcweb] What parts of SDP need to changeable by the JS application 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, 14 Feb 2012 13:43:57 -0000 My understanding based on earlier emails is that calling setLocalDescription informs the browser of the changes. In other words, the JS must call setLocalDescription after making any changes. =20 Somebody please let me know if I'm wrong... - Jim -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: Tuesday, February 14, 2012 7:27 AM To: Cullen Jennings; rtcweb@ietf.org Subject: Re: [rtcweb] What parts of SDP need to changeable by the JS application Hi, A related question is: if the JS App changes some information, does it need to inform the browser about it? OR, should the JS App only be allowed to change information which the browser does not need to be informed about? Regards, Christer =20 -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Cullen Jennings Sent: 13. helmikuuta 2012 17:19 To: rtcweb@ietf.org Subject: [rtcweb] What parts of SDP need to changeable by the JS application I'd like to figure out what parts of the SDP that the JS App needs to be able to change.=20 The one clear example I have heard is removing a codec that the App does not want to use. Are there others?=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 juberti@google.com Tue Feb 14 05:51: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 646C821F876D for ; Tue, 14 Feb 2012 05:51:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[AWL=0.277, 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 M3tKq9X9fgWF for ; Tue, 14 Feb 2012 05:51:21 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id A39E321F86F8 for ; Tue, 14 Feb 2012 05:51:21 -0800 (PST) Received: by qcsq5 with SMTP id q5so178044qcs.31 for ; Tue, 14 Feb 2012 05:51:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=MX31fBhqDuGbLRQOfairjm1/79BU/eMiNUCINR4SYXI=; b=h/8mqM6gIbKJz6ojYhy8y1Cu3r0Aexuz+yboUlNJ0YccingbR2sAofkxBIbbthYVps xxuJ8TbEHkGW1OI5EmVlo8oLksOoenaKe8ewavJjv0btRV11NzCStLSime919w4zHxf/ X+aP1sQAIshhx+T+oTcO1nkQ2aCca5M+UaIPA= Received: by 10.229.135.201 with SMTP id o9mr12176891qct.148.1329227480518; Tue, 14 Feb 2012 05:51:20 -0800 (PST) Received: by 10.229.135.201 with SMTP id o9mr12176874qct.148.1329227480331; Tue, 14 Feb 2012 05:51:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.45.213 with HTTP; Tue, 14 Feb 2012 05:51:00 -0800 (PST) In-Reply-To: <4F3A27F6.40203@alvestrand.no> References: <4F234B8B.4020204@jesup.org> <4F295660.3060001@jesup.org> <4F297011.1040507@jesup.org> <4F3A27F6.40203@alvestrand.no> From: Justin Uberti Date: Tue, 14 Feb 2012 08:51:00 -0500 Message-ID: To: Harald Alvestrand Content-Type: multipart/alternative; boundary=00248c6a862eca765404b8ece30b X-System-Of-Record: true X-Gm-Message-State: ALoCoQki7XHY8MDdgvnaHwrz4EXSAXm7dmHB71Fb/RdLd/KV24Hak9HAy1+V2SeZ1emESfs2jFHC9IMnNoa3eMPbtyknE9nXkRHa9SRjxlHrij3/rCQ62RlT1DnUWmdvN1WGyn/1+e4qrxqm0E8YRcLGCobCzmir/Q== Cc: rtcweb@ietf.org, "Suhas Nandakumar \(snandaku\)" , public-webrtc@w3.org Subject: Re: [rtcweb] ICE Candidate Gathering - Basic Thought 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, 14 Feb 2012 13:51:22 -0000 --00248c6a862eca765404b8ece30b Content-Type: text/plain; charset=UTF-8 On Tue, Feb 14, 2012 at 4:23 AM, Harald Alvestrand wrote: > On 02/13/2012 09:00 PM, Suhas Nandakumar (snandaku) wrote: > >> I was wondering why should we link ICE candidate gathering procedures to >> call setup flow. >> Can't this be done by browser periodically independent of RTCWeb call ? >> >> This may end up saving ton of time if the network topology doesn't >> change frequently. >> >> Is this a valid argument ? >> > the chief problem with that thought is that with current APIs, the browser > does not know which STUN/TURN server to use before the PeerConnection is > created (it's an init parameter). > > If we want this separation, we would have to create some object > (PeerConnectionFactory?) that would take the STUN/TURN server name as > parameters, gather the candidates and generate a PeerConnection object with > these candidates when required. > > This may be a Good Thing for other reasons (the rehydration case - > reestablishing a connection when the user does "reload"), but does > complicate the simple case. > > One issue with this is that a single preallocator can't do the right thing if you want to have multiple PeerConnections, or multiple unbundled m= lines. As an alternative, you could simply create a PeerConnection, call startIce to gather candidates (pre-call), and only getUserMedia/send the offer when you are ready to place the call. --00248c6a862eca765404b8ece30b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tue, Feb 14, 2012 at 4:23 AM, Harald = Alvestrand <ha= rald@alvestrand.no> wrote:
On 02/13/2012 09:00 PM, Suhas Nandakumar (snandaku) wrote= :
I was wondering why should we link ICE candidate gathering procedures to call setup flow.
Can't this be done by browser periodically independent of RTCWeb call ?=

This may end up saving ton of time if the network topology doesn't
change frequently.

Is this a valid argument ?
the chief problem with that thought is that with current APIs, the browser = does not know which STUN/TURN server to use before the PeerConnection is cr= eated (it's an init parameter).

If we want this separation, we would have to create some object (PeerConnec= tionFactory?) that would take the STUN/TURN server name as parameters, gath= er the candidates and generate a PeerConnection object with these candidate= s when required.

This may be a Good Thing for other reasons (the rehydration case - reestabl= ishing a connection when the user does "reload"), but does compli= cate the simple case.

=C2=A0
One issue with this is= that a single preallocator can't do the right thing if you want to hav= e multiple PeerConnections, or multiple unbundled m=3D lines.
As an alternative, you could simply create a PeerConnection, call star= tIce to gather candidates (pre-call), and only getUserMedia/send the offer = when you are ready to place the call.
--00248c6a862eca765404b8ece30b-- From juberti@google.com Tue Feb 14 05:59: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 3E8B121F876C for ; Tue, 14 Feb 2012 05:59:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.708 X-Spam-Level: X-Spam-Status: No, score=-102.708 tagged_above=-999 required=5 tests=[AWL=0.268, 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 3SgP9zEu5Fn7 for ; Tue, 14 Feb 2012 05:59:22 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1E17A21F8797 for ; Tue, 14 Feb 2012 05:59:22 -0800 (PST) Received: by qcsq5 with SMTP id q5so183189qcs.31 for ; Tue, 14 Feb 2012 05:59:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=33ugBEmo+eW4r9MKtYQnYTPIz79Kpn9lAa6zSrM1k8Q=; b=l0Ikr+p+3DH9wMzPlgLamiJYuajQGKniWPTimbo+ZGHnIeW7Un+xP1i71+jQw/ooUr +tEHrXQpFNb9wSl8uBKj15jHKJbY0am8G9a4TxUB+00RRB5d39bhdFsLfhCBGPGMZ7Oy Wbyh/xcnK55tZiE45hG4pAxnB4lRGs2ztY5Xs= Received: by 10.229.69.70 with SMTP id y6mr12331849qci.48.1329227961517; Tue, 14 Feb 2012 05:59:21 -0800 (PST) Received: by 10.229.69.70 with SMTP id y6mr12331840qci.48.1329227961361; Tue, 14 Feb 2012 05:59:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.45.213 with HTTP; Tue, 14 Feb 2012 05:59:01 -0800 (PST) In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E03F8A4@inba-mail01.sonusnet.com> References: <387F9047F55E8C42850AD6B3A7A03C6C0E03F8A4@inba-mail01.sonusnet.com> From: Justin Uberti Date: Tue, 14 Feb 2012 08:59:01 -0500 Message-ID: To: "Ravindran, Parthasarathi" Content-Type: multipart/alternative; boundary=0021cc023f1a7664e804b8ed00c2 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkeuq2L45zOseb88G9ygUGIa9Q94qPsgsNo2056N413wDn7ku8F0f9Zfb8qosRDTXnG9hbXTojofQgZvg5LWAt9535wH/3cMHgfiWJe3cK6X+YEg0fP2vDqBIcCosvchJiDwtZUiIPFQ9ZkowEgz9ZltYwZbQ== Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] Single offer with multiple answer handling in JSEP [was RE: New JSEP draft posted] 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, 14 Feb 2012 13:59:23 -0000 --0021cc023f1a7664e804b8ed00c2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Regarding your previous mail, an ANSWER after an ANSWER would either fail (if we wanted to simplify), or replace the previous ANSWER (essentially the same as if you had done setLocalDescription(OFFER, localDescription) followed by setRemoteDescription(ANSWER, answer2). In no case would it mix the descriptions/media from both answers. Other comments inline below. On Tue, Feb 14, 2012 at 1:24 AM, Ravindran, Parthasarathi < pravindran@sonusnet.com> wrote: > Hi Justin,**** > > ** ** > > Adding to my earlier mail, In case answer2 SDP is updated in offerer1 > browser without notifying answerer1, then answer1 will continue to transm= it > RTP which may not be desired behavior. IMO, we need to define this behavi= or > clearly in offerer side. Some of the possible solutions are**** > > > ** > > **1) **offerer1 has to send atleast RTCP BYE packets towards > answerer1 while accepting the answerer2 SDP. **** > > **2) **Throw callback to clear answer1 SDP towards offererJS. > The application which called setRemoteDescription twice should have the best idea about what is going on, and therefore is responsible for notifying answerer1 that its answer has been discarded, if it makes sense to do so. No callback should be needed here. > > **** > > Please let me know your opinion here.**** > > ** ** > > Thanks**** > > Partha **** > > ** ** > > *From:* Ravindran, Parthasarathi > *Sent:* Tuesday, February 14, 2012 12:07 AM > *To:* 'Justin Uberti'; rtcweb@ietf.org; public-webrtc@w3.org > *Subject:* Single offer with multiple answer handling in JSEP [was RE: > [rtcweb] New JSEP draft posted]**** > > ** ** > > Hi Justin,**** > > ** ** > > In the draft, it is not spelled out explicitly what is the expected > behavior in offerer browser in case multiple answer is received for singl= e > offer. Offer/answer exchange in offerer is as follows:**** > > ** ** > > OffererJS->OffererUA: var offer =3D pc.createOffer(null);**** > > OffererJS->OffererUA: pc.setLocalDescription(SDP_OFFER, offer);**** > > OffererJS->OffererUA: pc.setRemoteDescription(SDP_ANSWER, answer1);**** > > OffererUA->Answerer1UA: **** > > OffererJS->OffererUA: pc.setRemoteDescription(SDP_ANSWER, answer2);**** > > OffererUA->Answerer?UA: ?**** > > ** ** > > My understanding is that =E2=80=9Canswer2=E2=80=9D will update =E2=80=9Ca= nswer1=E2=80=9D in browser and > starting sending/receiving media towards answer2 media IP and port. Could > you please explain the expected behavior in offerer browser whether it > updates the media stream based on the last answer or mixes both answerer.= * > *** > > ** ** > > Thanks**** > > Partha**** > > ** ** > > *From:* rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] > *On Behalf Of *Justin Uberti > *Sent:* Thursday, February 09, 2012 2:27 AM > *To:* rtcweb@ietf.org; public-webrtc@w3.org > *Subject:* [rtcweb] New JSEP draft posted**** > > ** ** > > Now available at http://www.ietf.org/id/draft-uberti-rtcweb-jsep-01.txt**= * > * > > ** ** > > Includes changes based on implementation feedback, and I believe it > addresses most of the concerns raised in last week's interim meetings:***= * > > - Initial documentation provided for each API call, and what state change= s > it causes**** > > - More examples, including a complete basic sample application**** > > - Simplified approach to trickle candidate handling**** > > - Resolved concerns about how to separate SDP attributes into media / > transport**** > > - Provided encapsulation for SDP blobs and ICE candidate lines, in the > event we want to change encodings or provide helper functions for JS**** > > - Provided mechanism for limiting candidates to TURN-only**** > > - Resolved several implementation issues**** > > ** ** > > I have not yet addressed the non-overlapping codec concern mentioned in > the interim meeting. I think there are ways of handling this either in th= e > application or the implementation, but I wanted to get this -01 out first > for feedback.**** > --0021cc023f1a7664e804b8ed00c2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Regarding your previous mail, an ANSWER after an ANSWER would either fail (= if we wanted to simplify), or replace the previous ANSWER (essentially the = same as if you had done setLocalDescription(OFFER, localDescription) follow= ed by setRemoteDescription(ANSWER, answer2).

In no case would it mix the descriptions/media from both ans= wers.

Other comments inline below.

On Tue, Feb 14, 2012 at 1:24 AM, Ravindran, Parthasarath= i <pravindr= an@sonusnet.com> wrote:

Hi Justin,<= /span>

=C2=A0

Adding to my earlier mail= , In case answer2 SDP is updated in offerer1 browser without notifying answ= erer1, then answer1 will continue to transmit RTP which may not be desired behavior. IMO, we need to define this behavior clearly = in offerer side. Some of the possible solutions are

=C2=A0

1)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 offerer1 has to send= atleast RTCP BYE packets towards answerer1 while accepting the answerer2 S= DP.=C2=A0

2)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Throw callback to cl= ear answer1 SDP towards offererJS.


The application which called setRemoteDescription twice= should have the best idea about what is going on, and therefore is respons= ible for notifying answerer1 that its answer has been discarded, if it make= s sense to do so. No callback should be needed here.=C2=A0


Please let me know your o= pinion here.

=C2=A0

Thanks

Partha

=C2=A0

From: Ravindra= n, Parthasarathi
Sent: Tuesday, February 14, 2012 12:07 AM
To: 'Justin Uberti'; rtcweb@ietf.org; public-webrtc@w3.org
Subject: Single offer with multiple answer handling in JSEP [was RE:= [rtcweb] New JSEP draft posted]

=C2=A0

Hi Justin,<= /span>

=C2=A0

In the draft, it is not s= pelled out explicitly what is the expected behavior in offerer browser in c= ase multiple answer is received for single offer. Offer/answer exchange in offerer is as follows:

=C2=A0

OffererJS->OffererUA: var offer =3D pc.createOffer(null);=

OffererJS->OffererUA: pc.setLocalDescription(SDP_OFFER,= offer);

OffererJS->OffererUA:=C2=A0 pc.setRemoteDescription(SDP_ANSWER, ans=
wer1);
OffererUA->Answerer1UA: <media>
OffererJS->OffererUA:=C2=A0 pc.setRemoteDescription(SDP_ANSWER, ans=
wer2);
OffererUA->Answerer?UA: <media>?

=C2=A0

My understanding is that = =E2=80=9Canswer2=E2=80=9D will update =E2=80=9Canswer1=E2=80=9D in browser = and starting sending/receiving media towards answer2 media IP and port. Cou= ld you please explain the expected behavior in offerer browser whether it updates the me= dia stream based on the last answer or mixes both answerer.

=C2=A0

Thanks

Partha

=C2=A0

From: rtcweb-bounces= @ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Justin Uberti
Sent: Thursday, February 09, 2012 2:27 AM
To: rtcweb@ietf= .org; public-webrtc@w3.org
Subject: [rtcweb] New JSEP draft posted

=C2=A0

Now available at http://www.ietf.org/id/draft-uberti-rtcweb-jsep-01.txt

=C2=A0

Includes changes based on implementation feedback, a= nd I believe it addresses most of the concerns raised in last week's in= terim meetings:

- Initial documentation provided for each API call, = and what state changes it causes

- More examples, including a complete basic sample a= pplication

- Simplified approach to trickle candidate handling<= u>

- Resolved concerns about how to separate SDP attrib= utes into media / transport

- Provided encapsulation for SDP blobs and ICE candi= date lines, in the event we want to change encodings or provide helper func= tions for JS

- Provided mechanism for limiting candidates to TURN= -only

- Resolved several implementation issues

=C2=A0

I have not yet addressed the non-overlapping codec c= oncern mentioned in the interim meeting. I think there are ways of handling= this either in the application or the implementation, but I wanted to get = this -01 out first for feedback.


--0021cc023f1a7664e804b8ed00c2-- From harald@alvestrand.no Tue Feb 14 06:07: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 8033B21F8577 for ; Tue, 14 Feb 2012 06:07:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.5 X-Spam-Level: X-Spam-Status: No, score=-110.5 tagged_above=-999 required=5 tests=[AWL=0.098, 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 FUPc4meN+dco for ; Tue, 14 Feb 2012 06:07:40 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 38C5921F8575 for ; Tue, 14 Feb 2012 06:07:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 72D3339E10E; Tue, 14 Feb 2012 15:07:39 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4uUOOMjS5wJ; Tue, 14 Feb 2012 15:07:38 +0100 (CET) Received: from hta-dell.lul.corp.google.com (unknown [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 96BB139E0FD; Tue, 14 Feb 2012 15:07:38 +0100 (CET) Message-ID: <4F3A6AA9.60503@alvestrand.no> Date: Tue, 14 Feb 2012 15:07:37 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.26) Gecko/20120131 Thunderbird/3.1.18 MIME-Version: 1.0 To: Justin Uberti References: <4F234B8B.4020204@jesup.org> <4F295660.3060001@jesup.org> <4F297011.1040507@jesup.org> <4F3A27F6.40203@alvestrand.no> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000803060706040001080909" Cc: rtcweb@ietf.org, "Suhas Nandakumar \(snandaku\)" , public-webrtc@w3.org Subject: Re: [rtcweb] ICE Candidate Gathering - Basic Thought 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, 14 Feb 2012 14:07:41 -0000 This is a multi-part message in MIME format. --------------000803060706040001080909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 02/14/2012 02:51 PM, Justin Uberti wrote: > > > On Tue, Feb 14, 2012 at 4:23 AM, Harald Alvestrand > > wrote: > > On 02/13/2012 09:00 PM, Suhas Nandakumar (snandaku) wrote: > > I was wondering why should we link ICE candidate gathering > procedures to > call setup flow. > Can't this be done by browser periodically independent of > RTCWeb call ? > > This may end up saving ton of time if the network topology doesn't > change frequently. > > Is this a valid argument ? > > the chief problem with that thought is that with current APIs, the > browser does not know which STUN/TURN server to use before the > PeerConnection is created (it's an init parameter). > > If we want this separation, we would have to create some object > (PeerConnectionFactory?) that would take the STUN/TURN server name > as parameters, gather the candidates and generate a PeerConnection > object with these candidates when required. > > This may be a Good Thing for other reasons (the rehydration case - > reestablishing a connection when the user does "reload"), but does > complicate the simple case. > > One issue with this is that a single preallocator can't do the right > thing if you want to have multiple PeerConnections, or multiple > unbundled m= lines. If multiple local ports are needed (and the code seems to be simplest if they are): yes, we need to allocate more than one port. That doesn't mean that a preallocator can't do it, just that it needs to know how many are needed. > > As an alternative, you could simply create a PeerConnection, call > startIce to gather candidates (pre-call), and only getUserMedia/send > the offer when you are ready to place the call. Which made me realize that this isn't clear from the current drafts: If I do pc = new PeerConnection() pc.startIce() pc.CreateOffer() will the created offer contain the candidates that have been generated? If it does, it seems to me that people who don't need/can't use trickle candidates don't need to handle the ICE machinery at all. Harald --------------000803060706040001080909 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 02/14/2012 02:51 PM, Justin Uberti wrote:


On Tue, Feb 14, 2012 at 4:23 AM, Harald Alvestrand <harald@alvestrand.no> wrote:
On 02/13/2012 09:00 PM, Suhas Nandakumar (snandaku) wrote:
I was wondering why should we link ICE candidate gathering procedures to
call setup flow.
Can't this be done by browser periodically independent of RTCWeb call ?

This may end up saving ton of time if the network topology doesn't
change frequently.

Is this a valid argument ?
the chief problem with that thought is that with current APIs, the browser does not know which STUN/TURN server to use before the PeerConnection is created (it's an init parameter).

If we want this separation, we would have to create some object (PeerConnectionFactory?) that would take the STUN/TURN server name as parameters, gather the candidates and generate a PeerConnection object with these candidates when required.

This may be a Good Thing for other reasons (the rehydration case - reestablishing a connection when the user does "reload"), but does complicate the simple case.

 
One issue with this is that a single preallocator can't do the right thing if you want to have multiple PeerConnections, or multiple unbundled m= lines.
If multiple local ports are needed (and the code seems to be simplest if they are): yes, we need to allocate more than one port. That doesn't mean that a preallocator can't do it, just that it needs to know how many are needed.


As an alternative, you could simply create a PeerConnection, call startIce to gather candidates (pre-call), and only getUserMedia/send the offer when you are ready to place the call.

Which made me realize that this isn't clear from the current drafts: If I do

pc = new PeerConnection()
pc.startIce()
<wait 3 seconds>
pc.CreateOffer()

will the created offer contain the candidates that have been generated?

If it does, it seems to me that people who don't need/can't use trickle candidates don't need to handle the ICE machinery at all.

                    Harald


--------------000803060706040001080909-- From juberti@google.com Tue Feb 14 06:22: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 334D321F8319 for ; Tue, 14 Feb 2012 06:22:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.716 X-Spam-Level: X-Spam-Status: No, score=-102.716 tagged_above=-999 required=5 tests=[AWL=0.260, 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 IM8-ACkjOooG for ; Tue, 14 Feb 2012 06:22:22 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5C521F877E for ; Tue, 14 Feb 2012 06:22:21 -0800 (PST) Received: by qafi29 with SMTP id i29so2259917qaf.10 for ; Tue, 14 Feb 2012 06:22:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=bNWK5Y/KuPXlE93j196BFD71tjRZ03T/5i50tohf6MA=; b=SKTIHxOxIe6AA5olJAEVYLlVDRvLoiIQfmf2EzEZod/izWpKmAyEk30A+BIH2IgKJK OPdvdjCmCtwNiBWki9/3hWFqUXld9a4IZCkfvqiFoPNOjWItnSr22NrmfqizfVudG8+m tXeqAeQDU8535z4hpSFG8GBXdixu5+OiKqesU= Received: by 10.229.102.137 with SMTP id g9mr12381815qco.128.1329229341552; Tue, 14 Feb 2012 06:22:21 -0800 (PST) Received: by 10.229.102.137 with SMTP id g9mr12381804qco.128.1329229341391; Tue, 14 Feb 2012 06:22:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.45.213 with HTTP; Tue, 14 Feb 2012 06:21:50 -0800 (PST) In-Reply-To: <4F3A6AA9.60503@alvestrand.no> References: <4F234B8B.4020204@jesup.org> <4F295660.3060001@jesup.org> <4F297011.1040507@jesup.org> <4F3A27F6.40203@alvestrand.no> <4F3A6AA9.60503@alvestrand.no> From: Justin Uberti Date: Tue, 14 Feb 2012 09:21:50 -0500 Message-ID: To: Harald Alvestrand Content-Type: multipart/alternative; boundary=002354470f78b7fbe504b8ed521f X-System-Of-Record: true X-Gm-Message-State: ALoCoQlXZZ2ESB9uOopvdYUhorsRuNPEkNXnFiH/0SaqVTBwYA3VOTcIS8YgEjL+zJK4hxuApa8v7I5nAJdwvTqREfu9a8PcHvq1KLrUCyVt6XP3HXcKGcKsZmSXZlW6ALRuzIECT6nJ0NXh4IHP2KSdjkHcsB/kqA== Cc: rtcweb@ietf.org, "Suhas Nandakumar \(snandaku\)" , public-webrtc@w3.org Subject: Re: [rtcweb] ICE Candidate Gathering - Basic Thought 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, 14 Feb 2012 14:22:26 -0000 --002354470f78b7fbe504b8ed521f Content-Type: text/plain; charset=UTF-8 On Tue, Feb 14, 2012 at 9:07 AM, Harald Alvestrand wrote: > ** > On 02/14/2012 02:51 PM, Justin Uberti wrote: > > > > On Tue, Feb 14, 2012 at 4:23 AM, Harald Alvestrand wrote: > >> On 02/13/2012 09:00 PM, Suhas Nandakumar (snandaku) wrote: >> >>> I was wondering why should we link ICE candidate gathering procedures to >>> call setup flow. >>> Can't this be done by browser periodically independent of RTCWeb call ? >>> >>> This may end up saving ton of time if the network topology doesn't >>> change frequently. >>> >>> Is this a valid argument ? >>> >> the chief problem with that thought is that with current APIs, the >> browser does not know which STUN/TURN server to use before the >> PeerConnection is created (it's an init parameter). >> >> If we want this separation, we would have to create some object >> (PeerConnectionFactory?) that would take the STUN/TURN server name as >> parameters, gather the candidates and generate a PeerConnection object with >> these candidates when required. >> >> This may be a Good Thing for other reasons (the rehydration case - >> reestablishing a connection when the user does "reload"), but does >> complicate the simple case. >> >> > One issue with this is that a single preallocator can't do the right thing > if you want to have multiple PeerConnections, or multiple unbundled m= > lines. > > If multiple local ports are needed (and the code seems to be simplest if > they are): yes, we need to allocate more than one port. That doesn't mean > that a preallocator can't do it, just that it needs to know how many are > needed. > You are correct. I should have said that it is harder for the preallocator to know what to do (i.e. we would need more API for it). > > > > As an alternative, you could simply create a PeerConnection, call > startIce to gather candidates (pre-call), and only getUserMedia/send the > offer when you are ready to place the call. > > > Which made me realize that this isn't clear from the current drafts: If I > do > > pc = new PeerConnection() > pc.startIce() > > pc.CreateOffer() > > will the created offer contain the candidates that have been generated? > Yes. If you use the IceCallback, you can be notified when all the candidates are ready, instead of using a timeout. But a timeout would work too. > > If it does, it seems to me that people who don't need/can't use trickle > candidates don't need to handle the ICE machinery at all. > Exactly. I tried to indicate that in section 4.5 of the -01 draft. > > > Harald > > > --002354470f78b7fbe504b8ed521f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable




As an alternative, you could simply create a PeerConnection, call startIce to gather candidates (pre-call), and only getUserMedia/send the offer when you are ready to place the call.

Which made me realize that this isn't clear from the current drafts= : If I do

pc =3D new PeerConnection()
pc.startIce()
<wait 3 seconds>
pc.CreateOffer()

will the created offer contain the candidates that have been generated?

Yes. If you use th= e IceCallback, you can be notified when all the candidates are ready, inste= ad of using a timeout. But a timeout would work too.
=C2=A0

If it does, it seems to me that people who don't need/can't use trickle candidates don't need to handle the ICE machinery at all.

Exactly. I tried to indicate that in s= ection 4.5 of the -01 draft.=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Harald


On Tue, Feb 14, 2012 at 9:07 AM, Harald = Alvestrand <ha= rald@alvestrand.no> wrote:
=20 =20 =20
On 02/14/2012 02:51 PM, Justin Uberti wrote:


On Tue, Feb 14, 2012 at 4:23 AM, Harald Alvestrand <harald@alvestrand.no> wrote:
On 02/13/2012 09:00 PM, Suhas Nandakumar (snandaku) wrote:
I was wondering why should we link ICE candidate gathering procedures to
call setup flow.
Can't this be done by browser periodically independent of RTCWeb call ?

This may end up saving ton of time if the network topology doesn't
change frequently.

Is this a valid argument ?
the chief problem with that thought is that with current APIs, the browser does not know which STUN/TURN server to use before the PeerConnection is created (it's an init parameter).

If we want this separation, we would have to create some object (PeerConnectionFactory?) that would take the STUN/TURN server name as parameters, gather the candidates and generate a PeerConnection object with these candidates when required.

This may be a Good Thing for other reasons (the rehydration case - reestablishing a connection when the user does "reload"), but does complicate the simple case.

=C2=A0
One issue with this is that a single preallocator can't do the right thing if you want to have multiple PeerConnections, or multiple unbundled m=3D lines.
If multiple local ports are needed (and the code seems to be simplest if they are): yes, we need to allocate more than one port. That doesn't mean that a preallocator can't do it, just that it needs to know how many are needed.

You are correct. I should have said that it is harder for the preallocato= r to know what to do (i.e. we would need more API for it).=C2=A0

--002354470f78b7fbe504b8ed521f-- From pravindran@sonusnet.com Tue Feb 14 06:39: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 101BD21F8798 for ; Tue, 14 Feb 2012 06:39:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.015, 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 0WT96TV7Ofpi for ; Tue, 14 Feb 2012 06:39:44 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id C6B3321F87BA for ; Tue, 14 Feb 2012 06:39:40 -0800 (PST) Received: from sonusmail05.sonusnet.com (sonusmail05.sonusnet.com [10.128.32.155]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q1EEePoL017770; Tue, 14 Feb 2012 09:40:25 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Feb 2012 09:39:37 -0500 Received: from INBA-HUB02.sonusnet.com ([10.70.51.87]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Feb 2012 20:09:45 +0530 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; Tue, 14 Feb 2012 20:09:45 +0530 From: "Ravindran, Parthasarathi" To: Justin Uberti Thread-Topic: Single offer with multiple answer handling in JSEP [was RE: [rtcweb] New JSEP draft posted] Thread-Index: AQHM6uFaIZmsOFGRck2Q3yR4wFD2TJY8D6WAgABfAXA= Date: Tue, 14 Feb 2012 14:39:44 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E03FAB5@inba-mail01.sonusnet.com> References: <387F9047F55E8C42850AD6B3A7A03C6C0E03F8A4@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.70] Content-Type: multipart/alternative; boundary="_000_387F9047F55E8C42850AD6B3A7A03C6C0E03FAB5inbamail01sonus_" MIME-Version: 1.0 X-OriginalArrivalTime: 14 Feb 2012 14:39:45.0953 (UTC) FILETIME=[7F09B910:01CCEB26] Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] Single offer with multiple answer handling in JSEP [was RE: New JSEP draft posted] 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, 14 Feb 2012 14:39:48 -0000 --_000_387F9047F55E8C42850AD6B3A7A03C6C0E03FAB5inbamail01sonus_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSnVzdGluLA0KDQpJdCB3aWxsIGJlIGdvb2QgdG8gbWVudGlvbiBpbiB0aGUgSlNFUCBkcmFm dCAgdGhhdCBtdWx0aXBsZSBhbnN3ZXJzIGZvciBzaW5nbGUgb2ZmZXIgd2lsbCBub3QgbGVhZCB0 byBSVFAgTWl4aW5nIGFuZCBXZWJSVEMgY2xpZW50IGFjdHMgYXMgUlRQIEVuZHBvaW50Lg0KDQpG YWlsaW5nIHRoZSBzZWNvbmQgQW5zd2VyIHdpbGwgYmUgbGltaXRpbmcgdGhlIHByb3Zpc2lvbiBp biBSRkMgMzI2NCBvZmZlci9hbnN3ZXIgaXRzZWxmIGFzIFJGQyAzMjY0IHN1cHBvcnRzIHNpbmds ZSBvZmZlciB3aXRoIG11bHRpcGxlIGFuc3dlci4gQWxzbywgaXQgaXMgYmV0dGVyIHRvIGRlZmlu ZSB0aGUgYmVoYXZpb3IgaW4gQVBJIHJhdGhlciB0aGFuIHB1dHRpbmcgdGhpcyBzY2VuYXJpbyBp biB0aGUgYnJvd3NlciBpbXBsZW1lbnRhdGlvbiBzcGVjaWZpYy4gSW4gc2ltcGxlIHNjZW5hcmlv cyAobGlrZSBhbGVydGluZyB3aXRoIG9uZSBhbnN3ZXIsIGNvbm5lY3Qgd2l0aCBzZWNvbmQgYW5z d2VyKSwgcmVwbGFjaW5nIHRoZSBwcmV2aW91cyBBTlNXRVIgd2lsbCBiZSBleHBlY3RlZCBiZWhh dmlvci4gVGhpcyBtYXkgbm90IGJlIGRlc2lyZWQgYmVoYXZpb3IgaW4gY2FzZSB0d28gY29ubmVj dCByZXNwb25zZXMgZnJvbSBkaWZmZXJlbnQgV2ViUlRDIGNsaWVudHMgcmVjZWl2ZWQgd2l0aCBk aWZmZXJlbnQgYW5zd2VycyAgYnV0IHRoZXJlIGlzIG5vIG90aGVyIGFsdGVybmF0aXZlIHNvbHV0 aW9uIHBvc3NpYmxlIHdpdGhvdXQgbWl4aW5nLg0KDQpJTU8sIGl0IGlzIGJldHRlciB0byBkZWZp bmUgaXQgZXhwbGljaXRseSBpbiBKU0VQIHRoYXQg4oCcbGF0ZXN0IEFOU1dFUiB0byB0aGUgb2Zm ZXIgd2lsbCByZXBsYWNlIHRoZSBleGlzdGluZyBhbnN3ZXIgaXMgdGhlIGV4cGVjdGVkIGJlaGF2 aW9yIOKAnS4gQWxzbywgUGxlYXNlIG1lbnRpb25lZCB0aGF0IEpTIGFwcGxpY2F0aW9uIGlzIHJl c3BvbnNpYmxlIGZvciBkaXNjYXJkaW5nICh0ZXJtaW5hdGluZykgcHJldmlvdXMgQU5TV0VSIG5v dGlmaWNhdGlvbi4gICBQbGVhc2UgbGV0IG1lIHlvdXIgb3BpbmlvbiBvbiB0aGlzIGNsb3N1cmUu DQoNClRoYW5rcw0KUGFydGhhDQoNCkZyb206IEp1c3RpbiBVYmVydGkgW21haWx0bzpqdWJlcnRp QGdvb2dsZS5jb21dDQpTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAxNCwgMjAxMiA3OjI5IFBNDQpU bzogUmF2aW5kcmFuLCBQYXJ0aGFzYXJhdGhpDQpDYzogcnRjd2ViQGlldGYub3JnOyBwdWJsaWMt d2VicnRjQHczLm9yZw0KU3ViamVjdDogUmU6IFNpbmdsZSBvZmZlciB3aXRoIG11bHRpcGxlIGFu c3dlciBoYW5kbGluZyBpbiBKU0VQIFt3YXMgUkU6IFtydGN3ZWJdIE5ldyBKU0VQIGRyYWZ0IHBv c3RlZF0NCg0KUmVnYXJkaW5nIHlvdXIgcHJldmlvdXMgbWFpbCwgYW4gQU5TV0VSIGFmdGVyIGFu IEFOU1dFUiB3b3VsZCBlaXRoZXIgZmFpbCAoaWYgd2Ugd2FudGVkIHRvIHNpbXBsaWZ5KSwgb3Ig cmVwbGFjZSB0aGUgcHJldmlvdXMgQU5TV0VSIChlc3NlbnRpYWxseSB0aGUgc2FtZSBhcyBpZiB5 b3UgaGFkIGRvbmUgc2V0TG9jYWxEZXNjcmlwdGlvbihPRkZFUiwgbG9jYWxEZXNjcmlwdGlvbikg Zm9sbG93ZWQgYnkgc2V0UmVtb3RlRGVzY3JpcHRpb24oQU5TV0VSLCBhbnN3ZXIyKS4NCg0KSW4g bm8gY2FzZSB3b3VsZCBpdCBtaXggdGhlIGRlc2NyaXB0aW9ucy9tZWRpYSBmcm9tIGJvdGggYW5z d2Vycy4NCg0KT3RoZXIgY29tbWVudHMgaW5saW5lIGJlbG93Lg0KT24gVHVlLCBGZWIgMTQsIDIw MTIgYXQgMToyNCBBTSwgUmF2aW5kcmFuLCBQYXJ0aGFzYXJhdGhpIDxwcmF2aW5kcmFuQHNvbnVz bmV0LmNvbTxtYWlsdG86cHJhdmluZHJhbkBzb251c25ldC5jb20+PiB3cm90ZToNCkhpIEp1c3Rp biwNCg0KQWRkaW5nIHRvIG15IGVhcmxpZXIgbWFpbCwgSW4gY2FzZSBhbnN3ZXIyIFNEUCBpcyB1 cGRhdGVkIGluIG9mZmVyZXIxIGJyb3dzZXIgd2l0aG91dCBub3RpZnlpbmcgYW5zd2VyZXIxLCB0 aGVuIGFuc3dlcjEgd2lsbCBjb250aW51ZSB0byB0cmFuc21pdCBSVFAgd2hpY2ggbWF5IG5vdCBi ZSBkZXNpcmVkIGJlaGF2aW9yLiBJTU8sIHdlIG5lZWQgdG8gZGVmaW5lIHRoaXMgYmVoYXZpb3Ig Y2xlYXJseSBpbiBvZmZlcmVyIHNpZGUuIFNvbWUgb2YgdGhlIHBvc3NpYmxlIHNvbHV0aW9ucyBh cmUNCg0KDQoxKSAgICAgIG9mZmVyZXIxIGhhcyB0byBzZW5kIGF0bGVhc3QgUlRDUCBCWUUgcGFj a2V0cyB0b3dhcmRzIGFuc3dlcmVyMSB3aGlsZSBhY2NlcHRpbmcgdGhlIGFuc3dlcmVyMiBTRFAu DQoNCjIpICAgICAgVGhyb3cgY2FsbGJhY2sgdG8gY2xlYXIgYW5zd2VyMSBTRFAgdG93YXJkcyBv ZmZlcmVySlMuDQoNClRoZSBhcHBsaWNhdGlvbiB3aGljaCBjYWxsZWQgc2V0UmVtb3RlRGVzY3Jp cHRpb24gdHdpY2Ugc2hvdWxkIGhhdmUgdGhlIGJlc3QgaWRlYSBhYm91dCB3aGF0IGlzIGdvaW5n IG9uLCBhbmQgdGhlcmVmb3JlIGlzIHJlc3BvbnNpYmxlIGZvciBub3RpZnlpbmcgYW5zd2VyZXIx IHRoYXQgaXRzIGFuc3dlciBoYXMgYmVlbiBkaXNjYXJkZWQsIGlmIGl0IG1ha2VzIHNlbnNlIHRv IGRvIHNvLiBObyBjYWxsYmFjayBzaG91bGQgYmUgbmVlZGVkIGhlcmUuDQoNCg0KUGxlYXNlIGxl dCBtZSBrbm93IHlvdXIgb3BpbmlvbiBoZXJlLg0KDQpUaGFua3MNClBhcnRoYQ0KDQpGcm9tOiBS YXZpbmRyYW4sIFBhcnRoYXNhcmF0aGkNClNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDE0LCAyMDEy IDEyOjA3IEFNDQpUbzogJ0p1c3RpbiBVYmVydGknOyBydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0 Y3dlYkBpZXRmLm9yZz47IHB1YmxpYy13ZWJydGNAdzMub3JnPG1haWx0bzpwdWJsaWMtd2VicnRj QHczLm9yZz4NClN1YmplY3Q6IFNpbmdsZSBvZmZlciB3aXRoIG11bHRpcGxlIGFuc3dlciBoYW5k bGluZyBpbiBKU0VQIFt3YXMgUkU6IFtydGN3ZWJdIE5ldyBKU0VQIGRyYWZ0IHBvc3RlZF0NCg0K SGkgSnVzdGluLA0KDQpJbiB0aGUgZHJhZnQsIGl0IGlzIG5vdCBzcGVsbGVkIG91dCBleHBsaWNp dGx5IHdoYXQgaXMgdGhlIGV4cGVjdGVkIGJlaGF2aW9yIGluIG9mZmVyZXIgYnJvd3NlciBpbiBj YXNlIG11bHRpcGxlIGFuc3dlciBpcyByZWNlaXZlZCBmb3Igc2luZ2xlIG9mZmVyLiBPZmZlci9h bnN3ZXIgZXhjaGFuZ2UgaW4gb2ZmZXJlciBpcyBhcyBmb2xsb3dzOg0KDQoNCk9mZmVyZXJKUy0+ T2ZmZXJlclVBOiB2YXIgb2ZmZXIgPSBwYy5jcmVhdGVPZmZlcihudWxsKTsNCk9mZmVyZXJKUy0+ T2ZmZXJlclVBOiBwYy5zZXRMb2NhbERlc2NyaXB0aW9uKFNEUF9PRkZFUiwgb2ZmZXIpOw0KDQpP ZmZlcmVySlMtPk9mZmVyZXJVQTogIHBjLnNldFJlbW90ZURlc2NyaXB0aW9uKFNEUF9BTlNXRVIs IGFuc3dlcjEpOw0KDQpPZmZlcmVyVUEtPkFuc3dlcmVyMVVBOiA8bWVkaWE+DQoNCk9mZmVyZXJK Uy0+T2ZmZXJlclVBOiAgcGMuc2V0UmVtb3RlRGVzY3JpcHRpb24oU0RQX0FOU1dFUiwgYW5zd2Vy Mik7DQoNCk9mZmVyZXJVQS0+QW5zd2VyZXI/VUE6IDxtZWRpYT4/DQoNCk15IHVuZGVyc3RhbmRp bmcgaXMgdGhhdCDigJxhbnN3ZXIy4oCdIHdpbGwgdXBkYXRlIOKAnGFuc3dlcjHigJ0gaW4gYnJv d3NlciBhbmQgc3RhcnRpbmcgc2VuZGluZy9yZWNlaXZpbmcgbWVkaWEgdG93YXJkcyBhbnN3ZXIy IG1lZGlhIElQIGFuZCBwb3J0LiBDb3VsZCB5b3UgcGxlYXNlIGV4cGxhaW4gdGhlIGV4cGVjdGVk IGJlaGF2aW9yIGluIG9mZmVyZXIgYnJvd3NlciB3aGV0aGVyIGl0IHVwZGF0ZXMgdGhlIG1lZGlh IHN0cmVhbSBiYXNlZCBvbiB0aGUgbGFzdCBhbnN3ZXIgb3IgbWl4ZXMgYm90aCBhbnN3ZXJlci4N Cg0KVGhhbmtzDQpQYXJ0aGENCg0KRnJvbTogcnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRv OnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgSnVzdGluIFViZXJ0aQ0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDA5 LCAyMDEyIDI6MjcgQU0NClRvOiBydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9y Zz47IHB1YmxpYy13ZWJydGNAdzMub3JnPG1haWx0bzpwdWJsaWMtd2VicnRjQHczLm9yZz4NClN1 YmplY3Q6IFtydGN3ZWJdIE5ldyBKU0VQIGRyYWZ0IHBvc3RlZA0KDQpOb3cgYXZhaWxhYmxlIGF0 IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtdWJlcnRpLXJ0Y3dlYi1qc2VwLTAxLnR4dA0K DQpJbmNsdWRlcyBjaGFuZ2VzIGJhc2VkIG9uIGltcGxlbWVudGF0aW9uIGZlZWRiYWNrLCBhbmQg SSBiZWxpZXZlIGl0IGFkZHJlc3NlcyBtb3N0IG9mIHRoZSBjb25jZXJucyByYWlzZWQgaW4gbGFz dCB3ZWVrJ3MgaW50ZXJpbSBtZWV0aW5nczoNCi0gSW5pdGlhbCBkb2N1bWVudGF0aW9uIHByb3Zp ZGVkIGZvciBlYWNoIEFQSSBjYWxsLCBhbmQgd2hhdCBzdGF0ZSBjaGFuZ2VzIGl0IGNhdXNlcw0K LSBNb3JlIGV4YW1wbGVzLCBpbmNsdWRpbmcgYSBjb21wbGV0ZSBiYXNpYyBzYW1wbGUgYXBwbGlj YXRpb24NCi0gU2ltcGxpZmllZCBhcHByb2FjaCB0byB0cmlja2xlIGNhbmRpZGF0ZSBoYW5kbGlu Zw0KLSBSZXNvbHZlZCBjb25jZXJucyBhYm91dCBob3cgdG8gc2VwYXJhdGUgU0RQIGF0dHJpYnV0 ZXMgaW50byBtZWRpYSAvIHRyYW5zcG9ydA0KLSBQcm92aWRlZCBlbmNhcHN1bGF0aW9uIGZvciBT RFAgYmxvYnMgYW5kIElDRSBjYW5kaWRhdGUgbGluZXMsIGluIHRoZSBldmVudCB3ZSB3YW50IHRv IGNoYW5nZSBlbmNvZGluZ3Mgb3IgcHJvdmlkZSBoZWxwZXIgZnVuY3Rpb25zIGZvciBKUw0KLSBQ cm92aWRlZCBtZWNoYW5pc20gZm9yIGxpbWl0aW5nIGNhbmRpZGF0ZXMgdG8gVFVSTi1vbmx5DQot IFJlc29sdmVkIHNldmVyYWwgaW1wbGVtZW50YXRpb24gaXNzdWVzDQoNCkkgaGF2ZSBub3QgeWV0 IGFkZHJlc3NlZCB0aGUgbm9uLW92ZXJsYXBwaW5nIGNvZGVjIGNvbmNlcm4gbWVudGlvbmVkIGlu IHRoZSBpbnRlcmltIG1lZXRpbmcuIEkgdGhpbmsgdGhlcmUgYXJlIHdheXMgb2YgaGFuZGxpbmcg dGhpcyBlaXRoZXIgaW4gdGhlIGFwcGxpY2F0aW9uIG9yIHRoZSBpbXBsZW1lbnRhdGlvbiwgYnV0 IEkgd2FudGVkIHRvIGdldCB0aGlzIC0wMSBvdXQgZmlyc3QgZm9yIGZlZWRiYWNrLg0KDQo= --_000_387F9047F55E8C42850AD6B3A7A03C6C0E03FAB5inbamail01sonus_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmln aHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJp ZiI7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRN TCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAu TXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2lu OjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250 LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFt ZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4w aW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIEp1c3Rpbiw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkl0 IHdpbGwgYmUgZ29vZCB0byBtZW50aW9uIGluIHRoZSBKU0VQIGRyYWZ0ICZuYnNwO3RoYXQgbXVs dGlwbGUgYW5zd2VycyBmb3Igc2luZ2xlIG9mZmVyIHdpbGwgbm90IGxlYWQgdG8gUlRQIE1peGlu ZyBhbmQgV2ViUlRDIGNsaWVudCBhY3RzIGFzIFJUUCBFbmRwb2ludC4NCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RmFp bGluZyB0aGUgc2Vjb25kIEFuc3dlciB3aWxsIGJlIGxpbWl0aW5nIHRoZSBwcm92aXNpb24gaW4g UkZDIDMyNjQgb2ZmZXIvYW5zd2VyIGl0c2VsZiBhcyBSRkMgMzI2NCBzdXBwb3J0cyBzaW5nbGUg b2ZmZXIgd2l0aCBtdWx0aXBsZSBhbnN3ZXIuIEFsc28sIGl0IGlzDQogYmV0dGVyIHRvIGRlZmlu ZSB0aGUgYmVoYXZpb3IgaW4gQVBJIHJhdGhlciB0aGFuIHB1dHRpbmcgdGhpcyBzY2VuYXJpbyBp biB0aGUgYnJvd3NlciBpbXBsZW1lbnRhdGlvbiBzcGVjaWZpYy4gSW4gc2ltcGxlIHNjZW5hcmlv cyAobGlrZSBhbGVydGluZyB3aXRoIG9uZSBhbnN3ZXIsIGNvbm5lY3Qgd2l0aCBzZWNvbmQgYW5z d2VyKSwgcmVwbGFjaW5nIHRoZSBwcmV2aW91cyBBTlNXRVIgd2lsbCBiZSBleHBlY3RlZCBiZWhh dmlvci4gVGhpcyBtYXkNCiBub3QgYmUgZGVzaXJlZCBiZWhhdmlvciBpbiBjYXNlIHR3byBjb25u ZWN0IHJlc3BvbnNlcyBmcm9tIGRpZmZlcmVudCBXZWJSVEMgY2xpZW50cyByZWNlaXZlZCB3aXRo IGRpZmZlcmVudCBhbnN3ZXJzICZuYnNwO2J1dCB0aGVyZSBpcyBubyBvdGhlciBhbHRlcm5hdGl2 ZSBzb2x1dGlvbiBwb3NzaWJsZSB3aXRob3V0IG1peGluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklNTywgaXQgaXMg YmV0dGVyIHRvIGRlZmluZSBpdCBleHBsaWNpdGx5IGluIEpTRVAgdGhhdCDigJxsYXRlc3QgQU5T V0VSIHRvIHRoZSBvZmZlciB3aWxsIHJlcGxhY2UgdGhlIGV4aXN0aW5nIGFuc3dlciBpcyB0aGUg ZXhwZWN0ZWQgYmVoYXZpb3Ig4oCdLiBBbHNvLCBQbGVhc2UNCiBtZW50aW9uZWQgdGhhdCBKUyBh cHBsaWNhdGlvbiBpcyByZXNwb25zaWJsZSBmb3IgZGlzY2FyZGluZyAodGVybWluYXRpbmcpIHBy ZXZpb3VzIEFOU1dFUiBub3RpZmljYXRpb24uICZuYnNwOyZuYnNwO1BsZWFzZSBsZXQgbWUgeW91 ciBvcGluaW9uIG9uIHRoaXMgY2xvc3VyZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rczxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5QYXJ0aGE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4gSnVzdGluIFViZXJ0aSBbbWFpbHRvOmp1YmVydGlAZ29vZ2xlLmNvbV0NCjxi cj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBGZWJydWFyeSAxNCwgMjAxMiA3OjI5IFBNPGJyPg0K PGI+VG86PC9iPiBSYXZpbmRyYW4sIFBhcnRoYXNhcmF0aGk8YnI+DQo8Yj5DYzo8L2I+IHJ0Y3dl YkBpZXRmLm9yZzsgcHVibGljLXdlYnJ0Y0B3My5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6 IFNpbmdsZSBvZmZlciB3aXRoIG11bHRpcGxlIGFuc3dlciBoYW5kbGluZyBpbiBKU0VQIFt3YXMg UkU6IFtydGN3ZWJdIE5ldyBKU0VQIGRyYWZ0IHBvc3RlZF08bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRpbmcgeW91ciBwcmV2aW91cyBtYWlsLCBh biBBTlNXRVIgYWZ0ZXIgYW4gQU5TV0VSIHdvdWxkIGVpdGhlciBmYWlsIChpZiB3ZSB3YW50ZWQg dG8gc2ltcGxpZnkpLCBvciByZXBsYWNlIHRoZSBwcmV2aW91cyBBTlNXRVIgKGVzc2VudGlhbGx5 IHRoZSBzYW1lIGFzIGlmIHlvdSBoYWQgZG9uZSBzZXRMb2NhbERlc2NyaXB0aW9uKE9GRkVSLCBs b2NhbERlc2NyaXB0aW9uKSBmb2xsb3dlZCBieSBzZXRSZW1vdGVEZXNjcmlwdGlvbihBTlNXRVIs DQogYW5zd2VyMikuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JbiBubyBjYXNlIHdvdWxkIGl0IG1peCB0aGUgZGVzY3JpcHRpb25zL21lZGlhIGZyb20gYm90 aCBhbnN3ZXJzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPk90aGVyIGNvbW1lbnRzIGlubGlu ZSBiZWxvdy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBU dWUsIEZlYiAxNCwgMjAxMiBhdCAxOjI0IEFNLCBSYXZpbmRyYW4sIFBhcnRoYXNhcmF0aGkgJmx0 OzxhIGhyZWY9Im1haWx0bzpwcmF2aW5kcmFuQHNvbnVzbmV0LmNvbSI+cHJhdmluZHJhbkBzb251 c25ldC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+SGkgSnVzdGluLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFkZGluZyB0byBteSBlYXJsaWVyIG1haWws IEluIGNhc2UgYW5zd2VyMiBTRFAgaXMgdXBkYXRlZCBpbiBvZmZlcmVyMSBicm93c2VyIHdpdGhv dXQgbm90aWZ5aW5nIGFuc3dlcmVyMSwNCiB0aGVuIGFuc3dlcjEgd2lsbCBjb250aW51ZSB0byB0 cmFuc21pdCBSVFAgd2hpY2ggbWF5IG5vdCBiZSBkZXNpcmVkIGJlaGF2aW9yLiBJTU8sIHdlIG5l ZWQgdG8gZGVmaW5lIHRoaXMgYmVoYXZpb3IgY2xlYXJseSBpbiBvZmZlcmVyIHNpZGUuIFNvbWUg b2YgdGhlIHBvc3NpYmxlIHNvbHV0aW9ucyBhcmU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4xKTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5vZmZlcmVyMSBoYXMgdG8gc2Vu ZCBhdGxlYXN0IFJUQ1AgQllFIHBhY2tldHMgdG93YXJkcyBhbnN3ZXJlcjEgd2hpbGUgYWNjZXB0 aW5nIHRoZSBhbnN3ZXJlcjIgU0RQLiZuYnNwOw0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjIpPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPlRocm93IGNhbGxiYWNrIHRvIGNsZWFyIGFuc3dlcjEgU0RQIHRvd2FyZHMgb2ZmZXJl ckpTLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgYXBwbGljYXRpb24gd2hpY2ggY2Fs bGVkIHNldFJlbW90ZURlc2NyaXB0aW9uIHR3aWNlIHNob3VsZCBoYXZlIHRoZSBiZXN0IGlkZWEg YWJvdXQgd2hhdCBpcyBnb2luZyBvbiwgYW5kIHRoZXJlZm9yZSBpcyByZXNwb25zaWJsZSBmb3Ig bm90aWZ5aW5nIGFuc3dlcmVyMSB0aGF0IGl0cyBhbnN3ZXIgaGFzIGJlZW4gZGlzY2FyZGVkLCBp ZiBpdCBtYWtlcyBzZW5zZSB0byBkbyBzby4gTm8gY2FsbGJhY2sgc2hvdWxkDQogYmUgbmVlZGVk IGhlcmUuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0K PGRpdj4NCjxwPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UGxlYXNlIGxldCBtZSBr bm93IHlvdXIgb3BpbmlvbiBoZXJlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rczwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPlBhcnRoYQ0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiBSYXZpbmRyYW4sIFBhcnRoYXNhcmF0aGkNCjxicj4NCjxiPlNl bnQ6PC9iPiBUdWVzZGF5LCBGZWJydWFyeSAxNCwgMjAxMiAxMjowNyBBTTxicj4NCjxiPlRvOjwv Yj4gJ0p1c3RpbiBVYmVydGknOyA8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+cnRjd2ViQGlldGYub3JnPC9hPjsNCjxhIGhyZWY9Im1haWx0bzpwdWJsaWMt d2VicnRjQHczLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnB1YmxpYy13ZWJydGNAdzMub3JnPC9hPjxi cj4NCjxiPlN1YmplY3Q6PC9iPiBTaW5nbGUgb2ZmZXIgd2l0aCBtdWx0aXBsZSBhbnN3ZXIgaGFu ZGxpbmcgaW4gSlNFUCBbd2FzIFJFOiBbcnRjd2ViXSBOZXcgSlNFUCBkcmFmdCBwb3N0ZWRdPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIEp1c3Rp biw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5JbiB0aGUgZHJhZnQsIGl0IGlzIG5vdCBzcGVsbGVkIG91dCBleHBs aWNpdGx5IHdoYXQgaXMgdGhlIGV4cGVjdGVkIGJlaGF2aW9yIGluIG9mZmVyZXIgYnJvd3NlciBp bg0KIGNhc2UgbXVsdGlwbGUgYW5zd2VyIGlzIHJlY2VpdmVkIGZvciBzaW5nbGUgb2ZmZXIuIE9m ZmVyL2Fuc3dlciBleGNoYW5nZSBpbiBvZmZlcmVyIGlzIGFzIGZvbGxvd3M6PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHByZT5P ZmZlcmVySlMtJmd0O09mZmVyZXJVQTogdmFyIG9mZmVyID0gcGMuY3JlYXRlT2ZmZXIobnVsbCk7 PG86cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPk9mZmVy ZXJKUy0mZ3Q7T2ZmZXJlclVBOiBwYy5zZXRMb2NhbERlc2NyaXB0aW9uKFNEUF9PRkZFUiwgb2Zm ZXIpOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwcmU+T2ZmZXJlckpTLSZndDtPZmZlcmVyVUE6 Jm5ic3A7IHBjLnNldFJlbW90ZURlc2NyaXB0aW9uKFNEUF9BTlNXRVIsIGFuc3dlcjEpOzxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPk9mZmVyZXJVQS0mZ3Q7QW5zd2VyZXIxVUE6ICZsdDttZWRpYSZn dDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5PZmZlcmVySlMtJmd0O09mZmVyZXJVQTombmJzcDsg cGMuc2V0UmVtb3RlRGVzY3JpcHRpb24oU0RQX0FOU1dFUiwgYW5zd2VyMik7PG86cD48L286cD48 L3ByZT4NCjxwcmU+T2ZmZXJlclVBLSZndDtBbnN3ZXJlcj9VQTogJmx0O21lZGlhJmd0Oz88bzpw PjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IOKA nGFuc3dlcjLigJ0gd2lsbCB1cGRhdGUg4oCcYW5zd2VyMeKAnSBpbiBicm93c2VyIGFuZCBzdGFy dGluZyBzZW5kaW5nL3JlY2VpdmluZw0KIG1lZGlhIHRvd2FyZHMgYW5zd2VyMiBtZWRpYSBJUCBh bmQgcG9ydC4gQ291bGQgeW91IHBsZWFzZSBleHBsYWluIHRoZSBleHBlY3RlZCBiZWhhdmlvciBp biBvZmZlcmVyIGJyb3dzZXIgd2hldGhlciBpdCB1cGRhdGVzIHRoZSBtZWRpYSBzdHJlYW0gYmFz ZWQgb24gdGhlIGxhc3QgYW5zd2VyIG9yIG1peGVzIGJvdGggYW5zd2VyZXIuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+VGhhbmtzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UGFydGhhPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KPGEgaHJlZj0ibWFpbHRv OnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cnRjd2ViLWJvdW5jZXNA aWV0Zi5vcmc8L2E+IFs8YSBocmVmPSJtYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5tYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24g QmVoYWxmIE9mIDwvYj5KdXN0aW4gVWJlcnRpPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBG ZWJydWFyeSAwOSwgMjAxMiAyOjI3IEFNPGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86 cnRjd2ViQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cnRjd2ViQGlldGYub3JnPC9hPjsgPGEg aHJlZj0ibWFpbHRvOnB1YmxpYy13ZWJydGNAdzMub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpwdWJs aWMtd2VicnRjQHczLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW3J0Y3dlYl0gTmV3IEpT RVAgZHJhZnQgcG9zdGVkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPk5vdyBhdmFpbGFibGUgYXQNCjxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcv aWQvZHJhZnQtdWJlcnRpLXJ0Y3dlYi1qc2VwLTAxLnR4dCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0 cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC11YmVydGktcnRjd2ViLWpzZXAtMDEudHh0PC9hPjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkluY2x1ZGVz IGNoYW5nZXMgYmFzZWQgb24gaW1wbGVtZW50YXRpb24gZmVlZGJhY2ssIGFuZCBJIGJlbGlldmUg aXQgYWRkcmVzc2VzIG1vc3Qgb2YgdGhlIGNvbmNlcm5zIHJhaXNlZCBpbiBsYXN0IHdlZWsncyBp bnRlcmltIG1lZXRpbmdzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4tIEluaXRpYWwgZG9jdW1lbnRhdGlvbiBwcm92aWRlZCBmb3IgZWFjaCBB UEkgY2FsbCwgYW5kIHdoYXQgc3RhdGUgY2hhbmdlcyBpdCBjYXVzZXM8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LSBNb3JlIGV4YW1wbGVzLCBp bmNsdWRpbmcgYSBjb21wbGV0ZSBiYXNpYyBzYW1wbGUgYXBwbGljYXRpb248bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LSBTaW1wbGlmaWVkIGFw cHJvYWNoIHRvIHRyaWNrbGUgY2FuZGlkYXRlIGhhbmRsaW5nPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0gUmVzb2x2ZWQgY29uY2VybnMgYWJv dXQgaG93IHRvIHNlcGFyYXRlIFNEUCBhdHRyaWJ1dGVzIGludG8gbWVkaWEgLyB0cmFuc3BvcnQ8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LSBQ cm92aWRlZCBlbmNhcHN1bGF0aW9uIGZvciBTRFAgYmxvYnMgYW5kIElDRSBjYW5kaWRhdGUgbGlu ZXMsIGluIHRoZSBldmVudCB3ZSB3YW50IHRvIGNoYW5nZSBlbmNvZGluZ3Mgb3IgcHJvdmlkZSBo ZWxwZXIgZnVuY3Rpb25zIGZvciBKUzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4tIFByb3ZpZGVkIG1lY2hhbmlzbSBmb3IgbGltaXRpbmcgY2Fu ZGlkYXRlcyB0byBUVVJOLW9ubHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+LSBSZXNvbHZlZCBzZXZlcmFsIGltcGxlbWVudGF0aW9uIGlzc3Vl czxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+SSBoYXZlIG5vdCB5ZXQgYWRkcmVzc2VkIHRoZSBub24tb3ZlcmxhcHBpbmcgY29kZWMgY29u Y2VybiBtZW50aW9uZWQgaW4gdGhlIGludGVyaW0gbWVldGluZy4gSSB0aGluayB0aGVyZSBhcmUg d2F5cyBvZiBoYW5kbGluZyB0aGlzIGVpdGhlciBpbiB0aGUgYXBwbGljYXRpb24gb3IgdGhlIGlt cGxlbWVudGF0aW9uLA0KIGJ1dCBJIHdhbnRlZCB0byBnZXQgdGhpcyAtMDEgb3V0IGZpcnN0IGZv ciBmZWVkYmFjay48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_387F9047F55E8C42850AD6B3A7A03C6C0E03FAB5inbamail01sonus_-- From juberti@google.com Tue Feb 14 08:17: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 6365721F8471 for ; Tue, 14 Feb 2012 08:17:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.724 X-Spam-Level: X-Spam-Status: No, score=-102.724 tagged_above=-999 required=5 tests=[AWL=0.252, 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 QjNd5UD6RYP0 for ; Tue, 14 Feb 2012 08:17:37 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id A5FBD21F8474 for ; Tue, 14 Feb 2012 08:17:36 -0800 (PST) Received: by qcsq5 with SMTP id q5so89939qcs.31 for ; Tue, 14 Feb 2012 08:17:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=9dYwOURbecqXe4cs5ZCKoRSDiZz98PBTTtDd9rkaXJQ=; b=MDfUxH/uYsIrp9RW5fG2nhKydLjRArSmC5ZRctl1pfaZwL2uOXHrNQfv23jJDpC6tj MZVoqS/jzzB0lJNMLyDXEJgks8fw4zSofql/38vUObuZ/r5FNH52KhzoHKspkOyWUEiA W2hTnU75bssbgNFBIP+IdNXGX/guBvDT7BY1Y= Received: by 10.229.102.137 with SMTP id g9mr12622456qco.128.1329236256095; Tue, 14 Feb 2012 08:17:36 -0800 (PST) Received: by 10.229.102.137 with SMTP id g9mr12622407qco.128.1329236254692; Tue, 14 Feb 2012 08:17:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.45.213 with HTTP; Tue, 14 Feb 2012 08:17:14 -0800 (PST) In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E03FAB5@inba-mail01.sonusnet.com> References: <387F9047F55E8C42850AD6B3A7A03C6C0E03F8A4@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E03FAB5@inba-mail01.sonusnet.com> From: Justin Uberti Date: Tue, 14 Feb 2012 08:17:14 -0800 Message-ID: To: "Ravindran, Parthasarathi" Content-Type: multipart/alternative; boundary=002354470f78c8970b04b8eeee41 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlAo+lpwUknQLzT9KNirFPfLiNuMTfwlAg86j7RzASftf4ckEBaHu6xm9RYWKSocN5yKLoBPHqIUrNDcCXCz8UGrNexWvRATeKTj88m51gcTmmLVysQ8XHRc9d1g0xbMeb8etabc/bmuZg5PmjBeWYo+FPcZw== Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] Single offer with multiple answer handling in JSEP [was RE: New JSEP draft posted] 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, 14 Feb 2012 16:17:38 -0000 --002354470f78c8970b04b8eeee41 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Feb 14, 2012 at 6:39 AM, Ravindran, Parthasarathi < pravindran@sonusnet.com> wrote: > Hi Justin,**** > > ** ** > > It will be good to mention in the JSEP draft that multiple answers for > single offer will not lead to RTP Mixing and WebRTC client acts as RTP > Endpoint. **** > > ** ** > > Failing the second Answer will be limiting the provision in RFC 3264 > offer/answer itself as RFC 3264 supports single offer with multiple answe= r. > Also, it is better to define the behavior in API rather than putting this > scenario in the browser implementation specific. In simple scenarios (lik= e > alerting with one answer, connect with second answer), replacing the > previous ANSWER will be expected behavior. This may not be desired behavi= or > in case two connect responses from different WebRTC clients received with > different answers but there is no other alternative solution possible > without mixing. > Do you need to support 2 final answers, or would the provisional answer support provided via SDP_PRANSWER work for you? > **** > > ** ** > > IMO, it is better to define it explicitly in JSEP that =E2=80=9Clatest AN= SWER to > the offer will replace the existing answer is the expected behavior =E2= =80=9D. > Also, Please mentioned that JS application is responsible for discarding > (terminating) previous ANSWER notification. Please let me your opinion = on > this closure.**** > > ** ** > > Thanks**** > > Partha**** > > ** ** > > *From:* Justin Uberti [mailto:juberti@google.com] > *Sent:* Tuesday, February 14, 2012 7:29 PM > *To:* Ravindran, Parthasarathi > *Cc:* rtcweb@ietf.org; public-webrtc@w3.org > *Subject:* Re: Single offer with multiple answer handling in JSEP [was > RE: [rtcweb] New JSEP draft posted]**** > > ** ** > > Regarding your previous mail, an ANSWER after an ANSWER would either fail > (if we wanted to simplify), or replace the previous ANSWER (essentially t= he > same as if you had done setLocalDescription(OFFER, localDescription) > followed by setRemoteDescription(ANSWER, answer2).**** > > ** ** > > In no case would it mix the descriptions/media from both answers.**** > > ** ** > > Other comments inline below.**** > > On Tue, Feb 14, 2012 at 1:24 AM, Ravindran, Parthasarathi < > pravindran@sonusnet.com> wrote:**** > > Hi Justin,**** > > **** > > Adding to my earlier mail, In case answer2 SDP is updated in offerer1 > browser without notifying answerer1, then answer1 will continue to transm= it > RTP which may not be desired behavior. IMO, we need to define this behavi= or > clearly in offerer side. Some of the possible solutions are**** > > **** > > 1) offerer1 has to send atleast RTCP BYE packets towards answerer1 > while accepting the answerer2 SDP. **** > > 2) Throw callback to clear answer1 SDP towards offererJS.**** > > ** ** > > The application which called setRemoteDescription twice should have the > best idea about what is going on, and therefore is responsible for > notifying answerer1 that its answer has been discarded, if it makes sense > to do so. No callback should be needed here. **** > > ** ** > > Please let me know your opinion here.**** > > **** > > Thanks**** > > Partha **** > > **** > > *From:* Ravindran, Parthasarathi > *Sent:* Tuesday, February 14, 2012 12:07 AM > *To:* 'Justin Uberti'; rtcweb@ietf.org; public-webrtc@w3.org > *Subject:* Single offer with multiple answer handling in JSEP [was RE: > [rtcweb] New JSEP draft posted]**** > > **** > > Hi Justin,**** > > **** > > In the draft, it is not spelled out explicitly what is the expected > behavior in offerer browser in case multiple answer is received for singl= e > offer. Offer/answer exchange in offerer is as follows:**** > > **** > > OffererJS->OffererUA: var offer =3D pc.createOffer(null);**** > > OffererJS->OffererUA: pc.setLocalDescription(SDP_OFFER, offer);**** > > OffererJS->OffererUA: pc.setRemoteDescription(SDP_ANSWER, answer1);**** > > OffererUA->Answerer1UA: **** > > OffererJS->OffererUA: pc.setRemoteDescription(SDP_ANSWER, answer2);**** > > OffererUA->Answerer?UA: ?**** > > **** > > My understanding is that =E2=80=9Canswer2=E2=80=9D will update =E2=80=9Ca= nswer1=E2=80=9D in browser and > starting sending/receiving media towards answer2 media IP and port. Could > you please explain the expected behavior in offerer browser whether it > updates the media stream based on the last answer or mixes both answerer.= * > *** > > **** > > Thanks**** > > Partha**** > > **** > > *From:* rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] > *On Behalf Of *Justin Uberti > *Sent:* Thursday, February 09, 2012 2:27 AM > *To:* rtcweb@ietf.org; public-webrtc@w3.org > *Subject:* [rtcweb] New JSEP draft posted**** > > **** > > Now available at http://www.ietf.org/id/draft-uberti-rtcweb-jsep-01.txt**= * > * > > **** > > Includes changes based on implementation feedback, and I believe it > addresses most of the concerns raised in last week's interim meetings:***= * > > - Initial documentation provided for each API call, and what state change= s > it causes**** > > - More examples, including a complete basic sample application**** > > - Simplified approach to trickle candidate handling**** > > - Resolved concerns about how to separate SDP attributes into media / > transport**** > > - Provided encapsulation for SDP blobs and ICE candidate lines, in the > event we want to change encodings or provide helper functions for JS**** > > - Provided mechanism for limiting candidates to TURN-only**** > > - Resolved several implementation issues**** > > **** > > I have not yet addressed the non-overlapping codec concern mentioned in > the interim meeting. I think there are ways of handling this either in th= e > application or the implementation, but I wanted to get this -01 out first > for feedback.**** > > ** ** > --002354470f78c8970b04b8eeee41 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tue, Feb 14, 2012 at 6:39 AM, Ravindr= an, Parthasarathi <pravindran@sonusnet.com> wrote:

Hi Justin,<= /span>

=C2=A0

It will be good to mentio= n in the JSEP draft =C2=A0that multiple answers for single offer will not l= ead to RTP Mixing and WebRTC client acts as RTP Endpoint.

=C2=A0

Failing the second Answer= will be limiting the provision in RFC 3264 offer/answer itself as RFC 3264= supports single offer with multiple answer. Also, it is better to define the behavior in API rather than putting this scenario in = the browser implementation specific. In simple scenarios (like alerting wit= h one answer, connect with second answer), replacing the previous ANSWER wi= ll be expected behavior. This may not be desired behavior in case two connect responses from different WebRT= C clients received with different answers =C2=A0but there is no other alter= native solution possible without mixing.


Do you need to support 2 final answers, or would the pr= ovisional answer support provided via SDP_PRANSWER work for you?

=C2=A0

IMO, it is better to defi= ne it explicitly in JSEP that =E2=80=9Clatest ANSWER to the offer will repl= ace the existing answer is the expected behavior =E2=80=9D. Also, Please mentioned that JS application is responsible for discarding (terminating) = previous ANSWER notification. =C2=A0=C2=A0Please let me your opinion on thi= s closure.

=C2=A0

Thanks

Partha

=C2=A0

From: Justin U= berti [mailto:juber= ti@google.com]
Sent: Tuesday, February 14, 2012 7:29 PM
To: Ravindran, Parthasarathi
Cc: rtcweb@ietf= .org; public-= webrtc@w3.org
Subject: Re: Single offer with multiple answer handling in JSEP [was= RE: [rtcweb] New JSEP draft posted]

=C2=A0

Regarding your previous mail, an ANSWER after an ANS= WER would either fail (if we wanted to simplify), or replace the previous A= NSWER (essentially the same as if you had done setLocalDescription(OFFER, l= ocalDescription) followed by setRemoteDescription(ANSWER, answer2).

=C2=A0

In no case would it mix the descriptions/media from = both answers.

=C2=A0

Other comments inline= below.

On Tue, Feb 14, 2012 at 1:24 AM, Ravindran, Parthasa= rathi <prav= indran@sonusnet.com> wrote:

Hi Justin,<= u>

=C2=A0

Adding to my earlier mail= , In case answer2 SDP is updated in offerer1 browser without notifying answ= erer1, then answer1 will continue to transmit RTP which may not be desired behavi= or. IMO, we need to define this behavior clearly in offerer side. Some of t= he possible solutions are

=C2=A0

1)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 offerer1 has to send atleast RTCP BYE pac= kets towards answerer1 while accepting the answerer2 SDP.=C2=A0

2)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Throw callback to clear answer1 SDP towar= ds offererJS.

=C2=A0

The application which called setRemoteDescription tw= ice should have the best idea about what is going on, and therefore is resp= onsible for notifying answerer1 that its answer has been discarded, if it m= akes sense to do so. No callback should be needed here.=C2=A0

=C2=A0

Please let me know your o= pinion here.

=C2=A0

Thanks

Partha

=C2=A0

From: Ravindra= n, Parthasarathi
Sent: Tuesday, February 14, 2012 12:07 AM
To: 'Justin Uberti'; rtcweb@ietf.org; public-webrtc@w3.= org
Subject: Single offer with multiple answer handling in JSEP [was RE:= [rtcweb] New JSEP draft posted]

=C2=A0

Hi Justin,<= u>

=C2=A0

In the draft, it is not s= pelled out explicitly what is the expected behavior in offerer browser in case multiple answer is received for single offer. Offer/answer exchange i= n offerer is as follows:

=C2=A0

OffererJS->OffererUA: var offer =3D pc.createOffer(null);=

OffererJS->OffererUA: pc.setLocalDescription(SDP_OFFER,= offer);

OffererJS->OffererUA:=C2=A0 pc.setRemoteDescription(SDP_ANSWER, ans=
wer1);
OffererUA->Answerer1UA: <media>
OffererJS->OffererUA:=C2=A0 pc.setRemoteDescription(SDP_ANSWER, ans=
wer2);
OffererUA->Answerer?UA: <media>?

=C2=A0

My understanding is that = =E2=80=9Canswer2=E2=80=9D will update =E2=80=9Canswer1=E2=80=9D in browser = and starting sending/receiving media towards answer2 media IP and port. Could you please explain the expe= cted behavior in offerer browser whether it updates the media stream based = on the last answer or mixes both answerer.

=C2=A0

Thanks

Partha

=C2=A0

From: rtcweb-bounces= @ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Justin Uberti
Sent: Thursday, February 09, 2012 2:27 AM
To: rtcweb@ietf= .org; public-webrtc@w3.org
Subject: [rtcweb] New JSEP draft posted

=C2=A0

Now available at http://www.ietf.org/id/draft-uberti-rtcweb-jsep-01.txt

=C2=A0

Includes changes based on implementation feedback, a= nd I believe it addresses most of the concerns raised in last week's in= terim meetings:

- Initial documentation provided for each API call, = and what state changes it causes

- More examples, including a complete basic sample a= pplication

- Simplified approach to trickle candidate handling<= u>

- Resolved concerns about how to separate SDP attrib= utes into media / transport

- Provided encapsulation for SDP blobs and ICE candi= date lines, in the event we want to change encodings or provide helper func= tions for JS

- Provided mechanism for limiting candidates to TURN= -only

- Resolved several implementation issues

=C2=A0

I have not yet addressed the non-overlapping codec c= oncern mentioned in the interim meeting. I think there are ways of handling= this either in the application or the implementation, but I wanted to get this -01 out first for feedback.

=C2=A0


--002354470f78c8970b04b8eeee41-- From randell-ietf@jesup.org Tue Feb 14 08:27: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 AEAC021F8554 for ; Tue, 14 Feb 2012 08:27:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.683 X-Spam-Level: X-Spam-Status: No, score=-1.683 tagged_above=-999 required=5 tests=[AWL=-0.573, BAYES_05=-1.11] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQMdkKlh6XYM for ; Tue, 14 Feb 2012 08:27:25 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id C85E721F842C for ; Tue, 14 Feb 2012 08:27:25 -0800 (PST) Received: from pool-173-49-135-74.phlapa.fios.verizon.net ([173.49.135.74] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RxLDx-0004TP-5v for rtcweb@ietf.org; Tue, 14 Feb 2012 10:27:25 -0600 Message-ID: <4F3A8B2D.4000103@jesup.org> Date: Tue, 14 Feb 2012 11:26:21 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <29CD92BB-6764-4B87-AA99-ADB4B9685059@iii.ca> 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] What parts of SDP need to changeable by the JS application 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, 14 Feb 2012 16:27:26 -0000 On 2/13/2012 10:29 PM, Justin Uberti wrote: > We've had cases where we've needed to change the codec payload types, > codec parameters (e.g. bitrate), and SRTP keys. So, swapping payload values for different ones (the most common case I've seen is devices that insist that the payloads in each direction are the same numeric value). So long as generated answers follow that, it's generally not a problem in my experience; if that's the case, changing them might not be needed. I'll check some old notes to see if I've seen this need elsewhere. SRTP keys obviously only matters in the case of SDES. Codec Parameters: Have you had to modify any other than b=*? (which really isn't a codec parameter (fmtp) per-se). > For the rehydration use case, you really need to be able to supply just > about everything though. I'd assume in that case you'd largely cache the entire most recent accepted offer or answer. But rehydration could be very tricky; what if it occurs during a renegotiation? Also, I'm concerned about taking an answer and sending it as an offer, especially if there are SBCs in the loop (think gateway to legacy). *Reliable* rehydration is a tougher problem than I think people are waving their hands at. How long does the other side keep the call 'live' waiting for rehydration? Does this mean all calls have a delay before they end? Just ones where the two apps are the same? I think rehydration will be a rats-nest of edge cases and race conditions - especially when the page/app has more state than just the SDP media description (though that's largely the problem of the app). And I'm especially doubtful about rehydration in federation and legacy gateway cases. I realize that a lot of JS programmers have dealt with bugs by "reload the page!" (from what Justin and others said), but that seems like a huge cop-out to me. And yes, I know some other reasons were mentioned in the Interim - maybe those are valid, but a purposely-decided-on-reload is different than a user-accidental-reload - there can be communication that it's about to happen, for example, so the other side knows to wait, or to prepare states. But again, in federation cases this may fall down. -- Randell Jesup randell-ietf@jesup.org From juberti@google.com Tue Feb 14 08:40: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 28EB721F86E2 for ; Tue, 14 Feb 2012 08:40:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.731 X-Spam-Level: X-Spam-Status: No, score=-102.731 tagged_above=-999 required=5 tests=[AWL=0.245, 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 OPBUUVp0IIZF for ; Tue, 14 Feb 2012 08:40:22 -0800 (PST) Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 16F8F21F86B6 for ; Tue, 14 Feb 2012 08:40:21 -0800 (PST) Received: by qan41 with SMTP id 41so381235qan.10 for ; Tue, 14 Feb 2012 08:40:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=7L6RtHNIV0dKHk5PVcKgRfP3wEdShB/TSztL4Nvq4e4=; b=yURddpaFTLWo1o/dL/R4yGZ6Q0Bt3PRS+9LUPkd64z9GH4Kw3B2t0yIIS68KDTqx7s 8PY65dAlyD7ds5bwwOZJPkwY88fpD4TfiVFA5rXNv1dTybz8tSyWhIlMr5poRJbf0H0O bLNDDiSgY9S8dEQxvowzzP+4+C/A5LfZTTPOg= Received: by 10.229.69.70 with SMTP id y6mr12666378qci.48.1329237621498; Tue, 14 Feb 2012 08:40:21 -0800 (PST) Received: by 10.229.69.70 with SMTP id y6mr12666364qci.48.1329237621356; Tue, 14 Feb 2012 08:40:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.45.213 with HTTP; Tue, 14 Feb 2012 08:40:01 -0800 (PST) In-Reply-To: References: <29CD92BB-6764-4B87-AA99-ADB4B9685059@iii.ca> From: Justin Uberti Date: Tue, 14 Feb 2012 08:40:01 -0800 Message-ID: To: Jim Barnett Content-Type: multipart/alternative; boundary=0021cc023f1a3e39a004b8ef4064 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlhFieoELRSBbv0BNoigPiTmGl6lE9McWf2Vn8Z0DMAiAb3LW14Pa/1sTucaAVQMQntpHtKmK6qZrTHhwhMgW3d0lK4uOEInBZsM0kk/nsUMrrwE+XBndKuAAfAXjBxugK5kMiefh1PppjbMAm+ckSKW/Jo1w== Cc: rtcweb@ietf.org Subject: Re: [rtcweb] What parts of SDP need to changeable by the JSapplication 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, 14 Feb 2012 16:40:23 -0000 --0021cc023f1a3e39a004b8ef4064 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Feb 14, 2012 at 5:41 AM, Jim Barnett wr= ote: > In the rehydration case, much of what the JS is supplying are values that > the browser initially generated (but lost on page reload), so it=E2=80=99= s not > really _*changing*_ those values. The underlying question is: which > parts of the SDP can the JS change to something other than what the brows= er > initially provided? > As a start, I think the JS should be able to: - remove or reorder codecs (m=3D) - change codec attributes, if it makes sense (a=3Dfmtp; Partha also mention= ed ptime) - enable/disable BUNDLE (a=3Dgroup) - enable/disable RTCP mux (a=3Drtcp-mux) - reorder SRTP crypto-suites (a=3Dcrypto) - change SRTP parameters or keys (a=3Dcrypto) - change send resolution or framerate (TBD) - change desired recv resolution or framerate (TBD) - change total bandwidth (b=3D) - remove desired AVPF mechanisms (a=3Drtcp-fb) - remove RTP header extensions (a=3Drtphdr-ext) - add/change SSRC grouping (e.g. FID, RTX, etc) (a=3Dssrc-group) - add SSRC attributes (a=3Dssrc) - change ICE ufrag/password (a=3Dice-ufrag/pwd) - change media send/recv state (a=3Dsendonly/recvonly/inactive) The JS must inform the browser of most of these changes in order for them to work correctly. (Reordering codecs is one that could be done by JS without the browser knowing.) **** > > ** ** > > **- **Jim**** > > ** ** > > *From:* rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] *On > Behalf Of *Justin Uberti > *Sent:* Monday, February 13, 2012 10:30 PM > *To:* Cullen Jennings > *Cc:* rtcweb@ietf.org > > *Subject:* Re: [rtcweb] What parts of SDP need to changeable by the > JSapplication**** > > ** ** > > We've had cases where we've needed to change the codec payload types, > codec parameters (e.g. bitrate), and SRTP keys.**** > > ** ** > > For the rehydration use case, you really need to be able to supply just > about everything though.**** > > On Mon, Feb 13, 2012 at 10:19 AM, Cullen Jennings wrote:*= * > ** > > > I'd like to figure out what parts of the SDP that the JS App needs to be > able to change. > > The one clear example I have heard is removing a codec that the App does > not want to use. > > Are there others? > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb**** > > ** ** > --0021cc023f1a3e39a004b8ef4064 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tue, Feb 14, 2012 at 5:41 AM, Jim Bar= nett <Jim.Barnett@genesyslab.com> wrote:

In the rehydration case, much of what the JS= is supplying are values that the browser initially generated (but lost on = page reload), so it=E2=80=99s not really _changing_ those values.=C2= =A0 The underlying question is: which parts of the SDP can the JS change to= something other than what the browser initially provided?


As a start, I think the JS sho= uld be able to:
- remove or reorder codecs (m=3D)
- cha= nge codec attributes, if it makes sense (a=3Dfmtp; Partha also mentioned pt= ime)
- enable/disable BUNDLE (a=3Dgroup)
- enable/disable RTCP mu= x (a=3Drtcp-mux)
- reorder SRTP crypto-suites (a=3Dcrypto)
- change SRTP para= meters or keys (a=3Dcrypto)
- change send resolution or framerate= (TBD)
- change desired recv resolution or framerate (TBD)
- change total bandwidth (b=3D)
- remove desired AVPF mechanisms = (a=3Drtcp-fb)
- remove RTP header extensions (a=3Drtphdr-ext)
- add/change SSRC grouping (e.g. FID, RTX, etc) (a=3Dssrc-group)
- add SSRC attributes (a=3Dssrc)
- change ICE ufrag/password (a= =3Dice-ufrag/pwd)
- change media send/recv state (a=3Dsendonly/re= cvonly/inactive)

The JS must inform the browser of= most of these changes in order for them to work correctly. (Reordering cod= ecs is one that could be done by JS without the browser knowing.)

=C2=A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Jim=

=C2=A0

From: rtcweb-bounces@ietf.o= rg [mailto:rtcweb-bounces@ietf.org] On Behalf Of Justin Uberti
Sent: Monday, February 13, 2012 10:30 PM
To: Cullen Jennin= gs
Cc: rtcwe= b@ietf.org


Subject: Re: [rtcweb] What parts o= f SDP need to changeable by the JSapplication

=C2=A0

We've had cases where we've needed to change the codec payl= oad types, codec parameters (e.g. bitrate), and SRTP keys.

=C2=A0

For the rehydration use case= , you really need to be able to supply just about everything though.=

On Mon, Feb 13, 2012 at 10:19 AM, Cullen Jennin= gs <fluffy@iii.ca= > wrote:


I'd like to fig= ure out what parts of the SDP that the JS App needs to be able to change.
The one clear example I have heard is removing a codec that the App doe= s not want to use.

Are there others?
____________________________= ___________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

=C2=A0

<= /blockquote>

--0021cc023f1a3e39a004b8ef4064-- From juberti@google.com Tue Feb 14 08:49: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 1DA7121E8080 for ; Tue, 14 Feb 2012 08:49:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.905 X-Spam-Level: X-Spam-Status: No, score=-101.905 tagged_above=-999 required=5 tests=[AWL=-0.595, 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 pR8C9CrjJcVa for ; Tue, 14 Feb 2012 08:49:47 -0800 (PST) Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 1709D21F873A for ; Tue, 14 Feb 2012 08:49:47 -0800 (PST) Received: by qan41 with SMTP id 41so388258qan.10 for ; Tue, 14 Feb 2012 08:49:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=HBZ9HbkfkpuiC83WgCch81afx+PmTPwu3i7jFx+tZT8=; b=Oam7oikS7sTT64sMT/FYabVs6XsTafbZf71JM9W8YYStiM4PnzzhGWV25O3lNT5NC8 TKfEpSalTnsX9YCEcISh/rf0ywPovUnSPY3fXQ4sBVGT0Zd3xkYhFQwiX6Tdg60Z/red +CnqyfdX6LQqIJqWgVH+nYyVTBqJZkAEn1Ssg= Received: by 10.229.137.11 with SMTP id u11mr12844464qct.28.1329238186558; Tue, 14 Feb 2012 08:49:46 -0800 (PST) Received: by 10.229.137.11 with SMTP id u11mr12844456qct.28.1329238186377; Tue, 14 Feb 2012 08:49:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.45.213 with HTTP; Tue, 14 Feb 2012 08:49:26 -0800 (PST) In-Reply-To: <4F3A8B2D.4000103@jesup.org> References: <29CD92BB-6764-4B87-AA99-ADB4B9685059@iii.ca> <4F3A8B2D.4000103@jesup.org> From: Justin Uberti Date: Tue, 14 Feb 2012 08:49:26 -0800 Message-ID: To: Randell Jesup Content-Type: multipart/alternative; boundary=00235452ecf4ebc24e04b8ef61fd X-System-Of-Record: true X-Gm-Message-State: ALoCoQkUUVHuaQZ3p2UPc3kXoLKHpjDyaZDmx0bhKCP5ZkmP3o9G2Kvx1bRp4yXO3rq6PvVtgdSfiK1WYs6KA7sCQBpmW82zjgc/dvtJrd600Nrc40sBeNkpu9gBoIvKA5xB3SYmpR4eRCgJr3Cu9KbV2Q9Hwuj5Yw== Cc: rtcweb@ietf.org Subject: Re: [rtcweb] What parts of SDP need to changeable by the JS application 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, 14 Feb 2012 16:49:48 -0000 --00235452ecf4ebc24e04b8ef61fd Content-Type: text/plain; charset=UTF-8 On Tue, Feb 14, 2012 at 8:26 AM, Randell Jesup wrote: > On 2/13/2012 10:29 PM, Justin Uberti wrote: > >> We've had cases where we've needed to change the codec payload types, >> codec parameters (e.g. bitrate), and SRTP keys. >> > > So, swapping payload values for different ones (the most common case I've > seen is devices that insist that the payloads in each direction are the > same numeric value). So long as generated answers follow that, it's > generally not a problem in my experience; if that's the case, changing them > might not be needed. I'll check some old notes to see if I've seen this > need elsewhere. > > SRTP keys obviously only matters in the case of SDES. > > Codec Parameters: Have you had to modify any other than b=*? (which really > isn't a codec parameter (fmtp) per-se). > > > For the rehydration use case, you really need to be able to supply just >> about everything though. >> > > I'd assume in that case you'd largely cache the entire most recent > accepted offer or answer. But rehydration could be very tricky; what if it > occurs during a renegotiation? Also, I'm concerned about taking an answer > and sending it as an offer, especially if there are SBCs in the loop (think > gateway to legacy). > > *Reliable* rehydration is a tougher problem than I think people are waving > their hands at. How long does the other side keep the call 'live' waiting > for rehydration? The remote side needs to tolerate some network burps; walking into a location with bad wifi signal, a reset within the network; this would look exactly like one of those. > Does this mean all calls have a delay before they end? No; calls that end normally signal this via some sort of BYE message. > Just ones where the two apps are the same? I think rehydration will be a > rats-nest of edge cases and race conditions - especially when the page/app > has more state than just the SDP media description (though that's largely > the problem of the app). And I'm especially doubtful about rehydration in > federation and legacy gateway cases. > It might not be trivial for all applications, but I don't think that's a reason not to try. Once the APIs are there, I think it should be fairly easy to put together a demo and see if we are overlooking anything. > > I realize that a lot of JS programmers have dealt with bugs by "reload the > page!" (from what Justin and others said), but that seems like a huge > cop-out to me. And yes, I know some other reasons were mentioned in the > Interim - maybe those are valid, but a purposely-decided-on-reload is > different than a user-accidental-reload - there can be communication that > it's about to happen, for example, so the other side knows to wait, or to > prepare states. But again, in federation cases this may fall down. > > -- > Randell Jesup > randell-ietf@jesup.org > > ______________________________**_________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/**listinfo/rtcweb > --00235452ecf4ebc24e04b8ef61fd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tue, Feb 14, 2012 at 8:26 AM, Randell= Jesup <rand= ell-ietf@jesup.org> wrote:
On 2/13/2012 10:29 PM, Justin Uberti wrote:
We've had cases where we've needed to change the codec payload type= s,
codec parameters (e.g. bitrate), and SRTP keys.

So, swapping payload values for different ones (the most common case I'= ve seen is devices that insist that the payloads in each direction are the = same numeric value). =C2=A0So long as generated answers follow that, it'= ;s generally not a problem in my experience; if that's the case, changi= ng them might not be needed. =C2=A0I'll check some old notes to see if = I've seen this need elsewhere.

SRTP keys obviously only matters in the case of SDES.

Codec Parameters: Have you had to modify any other than b=3D*? (which reall= y isn't a codec parameter (fmtp) per-se).


For the rehydration use case, you really need to be able to supply just
about everything though.

I'd assume in that case you'd largely cache the entire most recent = accepted offer or answer. =C2=A0But rehydration could be very tricky; what = if it occurs during a renegotiation? =C2=A0Also, I'm concerned about ta= king an answer and sending it as an offer, especially if there are SBCs in = the loop (think gateway to legacy).

*Reliable* rehydration is a tougher problem than I think people are waving = their hands at. =C2=A0How long does the other side keep the call 'live&= #39; waiting for rehydration?

The remote s= ide needs to tolerate some network burps; walking into a location with bad = wifi signal, a reset within the network; this would look exactly like one o= f those.
=C2=A0
=C2=A0Does this mean all ca= lls have a delay before they end? =C2=A0

No= ; calls that end normally signal this via some sort of BYE message.
=C2=A0
Just ones where the two app= s are the same? =C2=A0I think rehydration will be a rats-nest of edge cases= and race conditions - especially when the page/app has more state than jus= t the SDP media description (though that's largely the problem of the a= pp). =C2=A0And I'm especially doubtful about rehydration in federation = and legacy gateway cases.

It might not be trivial for all applicatio= ns, but I don't think that's a reason not to try. Once the APIs are= there, I think it should be fairly easy to put together a demo and see if = we are overlooking anything.

I realize that a lot of JS programmers have dealt with bugs by "reload= the page!" (from what Justin and others said), but that seems like a = huge cop-out to me. =C2=A0And yes, I know some other reasons were mentioned= in the Interim - maybe those are valid, but a purposely-decided-on-reload = is different than a user-accidental-reload - there can be communication tha= t it's about to happen, for example, so the other side knows to wait, o= r to prepare states. =C2=A0But again, in federation cases this may fall dow= n.

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

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

--00235452ecf4ebc24e04b8ef61fd-- From pravindran@sonusnet.com Tue Feb 14 09:17: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 4083B21F8789 for ; Tue, 14 Feb 2012 09:17:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q3Yu6zFJj74V for ; Tue, 14 Feb 2012 09:17:11 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 9756421F8790 for ; Tue, 14 Feb 2012 09:17:10 -0800 (PST) Received: from sonusmail07.sonusnet.com (sonusmail07.sonusnet.com [10.128.32.157]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q1EHHtFp023579; Tue, 14 Feb 2012 12:17:55 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Feb 2012 12:17:05 -0500 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Feb 2012 22:47:13 +0530 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; Tue, 14 Feb 2012 22:47:13 +0530 From: "Ravindran, Parthasarathi" To: Justin Uberti Thread-Topic: Single offer with multiple answer handling in JSEP [was RE: [rtcweb] New JSEP draft posted] Thread-Index: AQHM6uFaIZmsOFGRck2Q3yR4wFD2TJY8D6WAgABfAXD//8edAIAAZLcQ Date: Tue, 14 Feb 2012 17:17:12 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E03FB7C@inba-mail01.sonusnet.com> References: <387F9047F55E8C42850AD6B3A7A03C6C0E03F8A4@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E03FAB5@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: [121.242.142.186] Content-Type: multipart/alternative; boundary="_000_387F9047F55E8C42850AD6B3A7A03C6C0E03FB7Cinbamail01sonus_" MIME-Version: 1.0 X-OriginalArrivalTime: 14 Feb 2012 17:17:13.0670 (UTC) FILETIME=[7E50EE60:01CCEB3C] Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] Single offer with multiple answer handling in JSEP [was RE: New JSEP draft posted] 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, 14 Feb 2012 17:17:12 -0000 --_000_387F9047F55E8C42850AD6B3A7A03C6C0E03FB7Cinbamail01sonus_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSnVzdGluLA0KDQpJbiB0aGlzIG1haWwgdGhyZWFkLCBMZXQgdXMgZGVmaW5lIHRoZSBiZWhh dmlvciBvZiBtdWx0aXBsZSAoYXRsZWFzdCB0d28pIGFuc3dlcnMgZm9yIHRoZSBzaW5nbGUgb2Zm ZXIgaW4gV2ViUlRDIGJyb3dzZXIuICBOb3csIFBsZWFzZSBsZXQgbWUga25vdyB5b3VyIG9waW5p b24gZm9yIG15IGJlbG93IG1haWwuDQoNClRoYW5rcw0KUGFydGhhDQoNCkZyb206IEp1c3RpbiBV YmVydGkgW21haWx0bzpqdWJlcnRpQGdvb2dsZS5jb21dDQpTZW50OiBUdWVzZGF5LCBGZWJydWFy eSAxNCwgMjAxMiA5OjQ3IFBNDQpUbzogUmF2aW5kcmFuLCBQYXJ0aGFzYXJhdGhpDQpDYzogcnRj d2ViQGlldGYub3JnOyBwdWJsaWMtd2VicnRjQHczLm9yZw0KU3ViamVjdDogUmU6IFNpbmdsZSBv ZmZlciB3aXRoIG11bHRpcGxlIGFuc3dlciBoYW5kbGluZyBpbiBKU0VQIFt3YXMgUkU6IFtydGN3 ZWJdIE5ldyBKU0VQIGRyYWZ0IHBvc3RlZF0NCg0KDQpPbiBUdWUsIEZlYiAxNCwgMjAxMiBhdCA2 OjM5IEFNLCBSYXZpbmRyYW4sIFBhcnRoYXNhcmF0aGkgPHByYXZpbmRyYW5Ac29udXNuZXQuY29t PG1haWx0bzpwcmF2aW5kcmFuQHNvbnVzbmV0LmNvbT4+IHdyb3RlOg0KSGkgSnVzdGluLA0KDQpJ dCB3aWxsIGJlIGdvb2QgdG8gbWVudGlvbiBpbiB0aGUgSlNFUCBkcmFmdCAgdGhhdCBtdWx0aXBs ZSBhbnN3ZXJzIGZvciBzaW5nbGUgb2ZmZXIgd2lsbCBub3QgbGVhZCB0byBSVFAgTWl4aW5nIGFu ZCBXZWJSVEMgY2xpZW50IGFjdHMgYXMgUlRQIEVuZHBvaW50Lg0KDQpGYWlsaW5nIHRoZSBzZWNv bmQgQW5zd2VyIHdpbGwgYmUgbGltaXRpbmcgdGhlIHByb3Zpc2lvbiBpbiBSRkMgMzI2NCBvZmZl ci9hbnN3ZXIgaXRzZWxmIGFzIFJGQyAzMjY0IHN1cHBvcnRzIHNpbmdsZSBvZmZlciB3aXRoIG11 bHRpcGxlIGFuc3dlci4gQWxzbywgaXQgaXMgYmV0dGVyIHRvIGRlZmluZSB0aGUgYmVoYXZpb3Ig aW4gQVBJIHJhdGhlciB0aGFuIHB1dHRpbmcgdGhpcyBzY2VuYXJpbyBpbiB0aGUgYnJvd3NlciBp bXBsZW1lbnRhdGlvbiBzcGVjaWZpYy4gSW4gc2ltcGxlIHNjZW5hcmlvcyAobGlrZSBhbGVydGlu ZyB3aXRoIG9uZSBhbnN3ZXIsIGNvbm5lY3Qgd2l0aCBzZWNvbmQgYW5zd2VyKSwgcmVwbGFjaW5n IHRoZSBwcmV2aW91cyBBTlNXRVIgd2lsbCBiZSBleHBlY3RlZCBiZWhhdmlvci4gVGhpcyBtYXkg bm90IGJlIGRlc2lyZWQgYmVoYXZpb3IgaW4gY2FzZSB0d28gY29ubmVjdCByZXNwb25zZXMgZnJv bSBkaWZmZXJlbnQgV2ViUlRDIGNsaWVudHMgcmVjZWl2ZWQgd2l0aCBkaWZmZXJlbnQgYW5zd2Vy cyAgYnV0IHRoZXJlIGlzIG5vIG90aGVyIGFsdGVybmF0aXZlIHNvbHV0aW9uIHBvc3NpYmxlIHdp dGhvdXQgbWl4aW5nLg0KDQpEbyB5b3UgbmVlZCB0byBzdXBwb3J0IDIgZmluYWwgYW5zd2Vycywg b3Igd291bGQgdGhlIHByb3Zpc2lvbmFsIGFuc3dlciBzdXBwb3J0IHByb3ZpZGVkIHZpYSBTRFBf UFJBTlNXRVIgd29yayBmb3IgeW91Pw0KDQpJTU8sIGl0IGlzIGJldHRlciB0byBkZWZpbmUgaXQg ZXhwbGljaXRseSBpbiBKU0VQIHRoYXQg4oCcbGF0ZXN0IEFOU1dFUiB0byB0aGUgb2ZmZXIgd2ls bCByZXBsYWNlIHRoZSBleGlzdGluZyBhbnN3ZXIgaXMgdGhlIGV4cGVjdGVkIGJlaGF2aW9yIOKA nS4gQWxzbywgUGxlYXNlIG1lbnRpb25lZCB0aGF0IEpTIGFwcGxpY2F0aW9uIGlzIHJlc3BvbnNp YmxlIGZvciBkaXNjYXJkaW5nICh0ZXJtaW5hdGluZykgcHJldmlvdXMgQU5TV0VSIG5vdGlmaWNh dGlvbi4gICBQbGVhc2UgbGV0IG1lIHlvdXIgb3BpbmlvbiBvbiB0aGlzIGNsb3N1cmUuDQoNClRo YW5rcw0KUGFydGhhDQoNCkZyb206IEp1c3RpbiBVYmVydGkgW21haWx0bzpqdWJlcnRpQGdvb2ds ZS5jb208bWFpbHRvOmp1YmVydGlAZ29vZ2xlLmNvbT5dDQpTZW50OiBUdWVzZGF5LCBGZWJydWFy eSAxNCwgMjAxMiA3OjI5IFBNDQpUbzogUmF2aW5kcmFuLCBQYXJ0aGFzYXJhdGhpDQpDYzogcnRj d2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+OyBwdWJsaWMtd2VicnRjQHczLm9y ZzxtYWlsdG86cHVibGljLXdlYnJ0Y0B3My5vcmc+DQpTdWJqZWN0OiBSZTogU2luZ2xlIG9mZmVy IHdpdGggbXVsdGlwbGUgYW5zd2VyIGhhbmRsaW5nIGluIEpTRVAgW3dhcyBSRTogW3J0Y3dlYl0g TmV3IEpTRVAgZHJhZnQgcG9zdGVkXQ0KDQpSZWdhcmRpbmcgeW91ciBwcmV2aW91cyBtYWlsLCBh biBBTlNXRVIgYWZ0ZXIgYW4gQU5TV0VSIHdvdWxkIGVpdGhlciBmYWlsIChpZiB3ZSB3YW50ZWQg dG8gc2ltcGxpZnkpLCBvciByZXBsYWNlIHRoZSBwcmV2aW91cyBBTlNXRVIgKGVzc2VudGlhbGx5 IHRoZSBzYW1lIGFzIGlmIHlvdSBoYWQgZG9uZSBzZXRMb2NhbERlc2NyaXB0aW9uKE9GRkVSLCBs b2NhbERlc2NyaXB0aW9uKSBmb2xsb3dlZCBieSBzZXRSZW1vdGVEZXNjcmlwdGlvbihBTlNXRVIs IGFuc3dlcjIpLg0KDQpJbiBubyBjYXNlIHdvdWxkIGl0IG1peCB0aGUgZGVzY3JpcHRpb25zL21l ZGlhIGZyb20gYm90aCBhbnN3ZXJzLg0KDQpPdGhlciBjb21tZW50cyBpbmxpbmUgYmVsb3cuDQpP biBUdWUsIEZlYiAxNCwgMjAxMiBhdCAxOjI0IEFNLCBSYXZpbmRyYW4sIFBhcnRoYXNhcmF0aGkg PHByYXZpbmRyYW5Ac29udXNuZXQuY29tPG1haWx0bzpwcmF2aW5kcmFuQHNvbnVzbmV0LmNvbT4+ IHdyb3RlOg0KSGkgSnVzdGluLA0KDQpBZGRpbmcgdG8gbXkgZWFybGllciBtYWlsLCBJbiBjYXNl IGFuc3dlcjIgU0RQIGlzIHVwZGF0ZWQgaW4gb2ZmZXJlcjEgYnJvd3NlciB3aXRob3V0IG5vdGlm eWluZyBhbnN3ZXJlcjEsIHRoZW4gYW5zd2VyMSB3aWxsIGNvbnRpbnVlIHRvIHRyYW5zbWl0IFJU UCB3aGljaCBtYXkgbm90IGJlIGRlc2lyZWQgYmVoYXZpb3IuIElNTywgd2UgbmVlZCB0byBkZWZp bmUgdGhpcyBiZWhhdmlvciBjbGVhcmx5IGluIG9mZmVyZXIgc2lkZS4gU29tZSBvZiB0aGUgcG9z c2libGUgc29sdXRpb25zIGFyZQ0KDQoNCjEpICAgICAgb2ZmZXJlcjEgaGFzIHRvIHNlbmQgYXRs ZWFzdCBSVENQIEJZRSBwYWNrZXRzIHRvd2FyZHMgYW5zd2VyZXIxIHdoaWxlIGFjY2VwdGluZyB0 aGUgYW5zd2VyZXIyIFNEUC4NCg0KMikgICAgICBUaHJvdyBjYWxsYmFjayB0byBjbGVhciBhbnN3 ZXIxIFNEUCB0b3dhcmRzIG9mZmVyZXJKUy4NCg0KVGhlIGFwcGxpY2F0aW9uIHdoaWNoIGNhbGxl ZCBzZXRSZW1vdGVEZXNjcmlwdGlvbiB0d2ljZSBzaG91bGQgaGF2ZSB0aGUgYmVzdCBpZGVhIGFi b3V0IHdoYXQgaXMgZ29pbmcgb24sIGFuZCB0aGVyZWZvcmUgaXMgcmVzcG9uc2libGUgZm9yIG5v dGlmeWluZyBhbnN3ZXJlcjEgdGhhdCBpdHMgYW5zd2VyIGhhcyBiZWVuIGRpc2NhcmRlZCwgaWYg aXQgbWFrZXMgc2Vuc2UgdG8gZG8gc28uIE5vIGNhbGxiYWNrIHNob3VsZCBiZSBuZWVkZWQgaGVy ZS4NCg0KDQpQbGVhc2UgbGV0IG1lIGtub3cgeW91ciBvcGluaW9uIGhlcmUuDQoNClRoYW5rcw0K UGFydGhhDQoNCkZyb206IFJhdmluZHJhbiwgUGFydGhhc2FyYXRoaQ0KU2VudDogVHVlc2RheSwg RmVicnVhcnkgMTQsIDIwMTIgMTI6MDcgQU0NClRvOiAnSnVzdGluIFViZXJ0aSc7IHJ0Y3dlYkBp ZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPjsgcHVibGljLXdlYnJ0Y0B3My5vcmc8bWFp bHRvOnB1YmxpYy13ZWJydGNAdzMub3JnPg0KU3ViamVjdDogU2luZ2xlIG9mZmVyIHdpdGggbXVs dGlwbGUgYW5zd2VyIGhhbmRsaW5nIGluIEpTRVAgW3dhcyBSRTogW3J0Y3dlYl0gTmV3IEpTRVAg ZHJhZnQgcG9zdGVkXQ0KDQpIaSBKdXN0aW4sDQoNCkluIHRoZSBkcmFmdCwgaXQgaXMgbm90IHNw ZWxsZWQgb3V0IGV4cGxpY2l0bHkgd2hhdCBpcyB0aGUgZXhwZWN0ZWQgYmVoYXZpb3IgaW4gb2Zm ZXJlciBicm93c2VyIGluIGNhc2UgbXVsdGlwbGUgYW5zd2VyIGlzIHJlY2VpdmVkIGZvciBzaW5n bGUgb2ZmZXIuIE9mZmVyL2Fuc3dlciBleGNoYW5nZSBpbiBvZmZlcmVyIGlzIGFzIGZvbGxvd3M6 DQoNCg0KT2ZmZXJlckpTLT5PZmZlcmVyVUE6IHZhciBvZmZlciA9IHBjLmNyZWF0ZU9mZmVyKG51 bGwpOw0KT2ZmZXJlckpTLT5PZmZlcmVyVUE6IHBjLnNldExvY2FsRGVzY3JpcHRpb24oU0RQX09G RkVSLCBvZmZlcik7DQoNCk9mZmVyZXJKUy0+T2ZmZXJlclVBOiAgcGMuc2V0UmVtb3RlRGVzY3Jp cHRpb24oU0RQX0FOU1dFUiwgYW5zd2VyMSk7DQoNCk9mZmVyZXJVQS0+QW5zd2VyZXIxVUE6IDxt ZWRpYT4NCg0KT2ZmZXJlckpTLT5PZmZlcmVyVUE6ICBwYy5zZXRSZW1vdGVEZXNjcmlwdGlvbihT RFBfQU5TV0VSLCBhbnN3ZXIyKTsNCg0KT2ZmZXJlclVBLT5BbnN3ZXJlcj9VQTogPG1lZGlhPj8N Cg0KTXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IOKAnGFuc3dlcjLigJ0gd2lsbCB1cGRhdGUg4oCc YW5zd2VyMeKAnSBpbiBicm93c2VyIGFuZCBzdGFydGluZyBzZW5kaW5nL3JlY2VpdmluZyBtZWRp YSB0b3dhcmRzIGFuc3dlcjIgbWVkaWEgSVAgYW5kIHBvcnQuIENvdWxkIHlvdSBwbGVhc2UgZXhw bGFpbiB0aGUgZXhwZWN0ZWQgYmVoYXZpb3IgaW4gb2ZmZXJlciBicm93c2VyIHdoZXRoZXIgaXQg dXBkYXRlcyB0aGUgbWVkaWEgc3RyZWFtIGJhc2VkIG9uIHRoZSBsYXN0IGFuc3dlciBvciBtaXhl cyBib3RoIGFuc3dlcmVyLg0KDQpUaGFua3MNClBhcnRoYQ0KDQpGcm9tOiBydGN3ZWItYm91bmNl c0BpZXRmLm9yZzxtYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86cnRjd2Vi LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKdXN0aW4gVWJlcnRpDQpTZW50OiBUaHVy c2RheSwgRmVicnVhcnkgMDksIDIwMTIgMjoyNyBBTQ0KVG86IHJ0Y3dlYkBpZXRmLm9yZzxtYWls dG86cnRjd2ViQGlldGYub3JnPjsgcHVibGljLXdlYnJ0Y0B3My5vcmc8bWFpbHRvOnB1YmxpYy13 ZWJydGNAdzMub3JnPg0KU3ViamVjdDogW3J0Y3dlYl0gTmV3IEpTRVAgZHJhZnQgcG9zdGVkDQoN Ck5vdyBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC11YmVydGktcnRj d2ViLWpzZXAtMDEudHh0DQoNCkluY2x1ZGVzIGNoYW5nZXMgYmFzZWQgb24gaW1wbGVtZW50YXRp b24gZmVlZGJhY2ssIGFuZCBJIGJlbGlldmUgaXQgYWRkcmVzc2VzIG1vc3Qgb2YgdGhlIGNvbmNl cm5zIHJhaXNlZCBpbiBsYXN0IHdlZWsncyBpbnRlcmltIG1lZXRpbmdzOg0KLSBJbml0aWFsIGRv Y3VtZW50YXRpb24gcHJvdmlkZWQgZm9yIGVhY2ggQVBJIGNhbGwsIGFuZCB3aGF0IHN0YXRlIGNo YW5nZXMgaXQgY2F1c2VzDQotIE1vcmUgZXhhbXBsZXMsIGluY2x1ZGluZyBhIGNvbXBsZXRlIGJh c2ljIHNhbXBsZSBhcHBsaWNhdGlvbg0KLSBTaW1wbGlmaWVkIGFwcHJvYWNoIHRvIHRyaWNrbGUg Y2FuZGlkYXRlIGhhbmRsaW5nDQotIFJlc29sdmVkIGNvbmNlcm5zIGFib3V0IGhvdyB0byBzZXBh cmF0ZSBTRFAgYXR0cmlidXRlcyBpbnRvIG1lZGlhIC8gdHJhbnNwb3J0DQotIFByb3ZpZGVkIGVu Y2Fwc3VsYXRpb24gZm9yIFNEUCBibG9icyBhbmQgSUNFIGNhbmRpZGF0ZSBsaW5lcywgaW4gdGhl IGV2ZW50IHdlIHdhbnQgdG8gY2hhbmdlIGVuY29kaW5ncyBvciBwcm92aWRlIGhlbHBlciBmdW5j dGlvbnMgZm9yIEpTDQotIFByb3ZpZGVkIG1lY2hhbmlzbSBmb3IgbGltaXRpbmcgY2FuZGlkYXRl cyB0byBUVVJOLW9ubHkNCi0gUmVzb2x2ZWQgc2V2ZXJhbCBpbXBsZW1lbnRhdGlvbiBpc3N1ZXMN Cg0KSSBoYXZlIG5vdCB5ZXQgYWRkcmVzc2VkIHRoZSBub24tb3ZlcmxhcHBpbmcgY29kZWMgY29u Y2VybiBtZW50aW9uZWQgaW4gdGhlIGludGVyaW0gbWVldGluZy4gSSB0aGluayB0aGVyZSBhcmUg d2F5cyBvZiBoYW5kbGluZyB0aGlzIGVpdGhlciBpbiB0aGUgYXBwbGljYXRpb24gb3IgdGhlIGlt cGxlbWVudGF0aW9uLCBidXQgSSB3YW50ZWQgdG8gZ2V0IHRoaXMgLTAxIG91dCBmaXJzdCBmb3Ig ZmVlZGJhY2suDQoNCg0K --_000_387F9047F55E8C42850AD6B3A7A03C6C0E03FB7Cinbamail01sonus_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmln aHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJp ZiI7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRN TCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAu TXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2lu OjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250 LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFt ZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4w aW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIEp1c3Rpbiw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklu IHRoaXMgbWFpbCB0aHJlYWQsIExldCB1cyBkZWZpbmUgdGhlIGJlaGF2aW9yIG9mIG11bHRpcGxl IChhdGxlYXN0IHR3bykgYW5zd2VycyBmb3IgdGhlIHNpbmdsZSBvZmZlciBpbiBXZWJSVEMgYnJv d3Nlci4gJm5ic3A7Tm93LCBQbGVhc2UgbGV0IG1lIGtub3cgeW91ciBvcGluaW9uDQogZm9yIG15 IGJlbG93IG1haWwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+UGFydGhhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJs dWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg MGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEp1 c3RpbiBVYmVydGkgW21haWx0bzpqdWJlcnRpQGdvb2dsZS5jb21dDQo8YnI+DQo8Yj5TZW50Ojwv Yj4gVHVlc2RheSwgRmVicnVhcnkgMTQsIDIwMTIgOTo0NyBQTTxicj4NCjxiPlRvOjwvYj4gUmF2 aW5kcmFuLCBQYXJ0aGFzYXJhdGhpPGJyPg0KPGI+Q2M6PC9iPiBydGN3ZWJAaWV0Zi5vcmc7IHB1 YmxpYy13ZWJydGNAdzMub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBTaW5nbGUgb2ZmZXIg d2l0aCBtdWx0aXBsZSBhbnN3ZXIgaGFuZGxpbmcgaW4gSlNFUCBbd2FzIFJFOiBbcnRjd2ViXSBO ZXcgSlNFUCBkcmFmdCBwb3N0ZWRdPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIEZlYiAxNCwgMjAxMiBh dCA2OjM5IEFNLCBSYXZpbmRyYW4sIFBhcnRoYXNhcmF0aGkgJmx0OzxhIGhyZWY9Im1haWx0bzpw cmF2aW5kcmFuQHNvbnVzbmV0LmNvbSI+cHJhdmluZHJhbkBzb251c25ldC5jb208L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgSnVzdGluLDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkl0IHdpbGwgYmUgZ29vZCB0byBtZW50aW9uIGluIHRoZSBKU0VQIGRyYWZ0 ICZuYnNwO3RoYXQgbXVsdGlwbGUgYW5zd2VycyBmb3Igc2luZ2xlIG9mZmVyIHdpbGwgbm90IGxl YWQNCiB0byBSVFAgTWl4aW5nIGFuZCBXZWJSVEMgY2xpZW50IGFjdHMgYXMgUlRQIEVuZHBvaW50 LiA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5GYWlsaW5nIHRoZSBzZWNvbmQgQW5zd2VyIHdpbGwgYmUgbGltaXRp bmcgdGhlIHByb3Zpc2lvbiBpbiBSRkMgMzI2NCBvZmZlci9hbnN3ZXIgaXRzZWxmIGFzIFJGQyAz MjY0DQogc3VwcG9ydHMgc2luZ2xlIG9mZmVyIHdpdGggbXVsdGlwbGUgYW5zd2VyLiBBbHNvLCBp dCBpcyBiZXR0ZXIgdG8gZGVmaW5lIHRoZSBiZWhhdmlvciBpbiBBUEkgcmF0aGVyIHRoYW4gcHV0 dGluZyB0aGlzIHNjZW5hcmlvIGluIHRoZSBicm93c2VyIGltcGxlbWVudGF0aW9uIHNwZWNpZmlj LiBJbiBzaW1wbGUgc2NlbmFyaW9zIChsaWtlIGFsZXJ0aW5nIHdpdGggb25lIGFuc3dlciwgY29u bmVjdCB3aXRoIHNlY29uZCBhbnN3ZXIpLCByZXBsYWNpbmcNCiB0aGUgcHJldmlvdXMgQU5TV0VS IHdpbGwgYmUgZXhwZWN0ZWQgYmVoYXZpb3IuIFRoaXMgbWF5IG5vdCBiZSBkZXNpcmVkIGJlaGF2 aW9yIGluIGNhc2UgdHdvIGNvbm5lY3QgcmVzcG9uc2VzIGZyb20gZGlmZmVyZW50IFdlYlJUQyBj bGllbnRzIHJlY2VpdmVkIHdpdGggZGlmZmVyZW50IGFuc3dlcnMgJm5ic3A7YnV0IHRoZXJlIGlz IG5vIG90aGVyIGFsdGVybmF0aXZlIHNvbHV0aW9uIHBvc3NpYmxlIHdpdGhvdXQgbWl4aW5nLjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5EbyB5b3UgbmVlZCB0byBzdXBwb3J0IDIgZmluYWwgYW5zd2Vycywgb3Igd291 bGQgdGhlIHByb3Zpc2lvbmFsIGFuc3dlciBzdXBwb3J0IHByb3ZpZGVkIHZpYSBTRFBfUFJBTlNX RVIgd29yayBmb3IgeW91PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBp biAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5JTU8sIGl0IGlzIGJldHRlciB0byBkZWZpbmUgaXQgZXhwbGljaXRseSBpbiBKU0VQIHRoYXQg 4oCcbGF0ZXN0IEFOU1dFUiB0byB0aGUgb2ZmZXIgd2lsbCByZXBsYWNlIHRoZQ0KIGV4aXN0aW5n IGFuc3dlciBpcyB0aGUgZXhwZWN0ZWQgYmVoYXZpb3Ig4oCdLiBBbHNvLCBQbGVhc2UgbWVudGlv bmVkIHRoYXQgSlMgYXBwbGljYXRpb24gaXMgcmVzcG9uc2libGUgZm9yIGRpc2NhcmRpbmcgKHRl cm1pbmF0aW5nKSBwcmV2aW91cyBBTlNXRVIgbm90aWZpY2F0aW9uLiAmbmJzcDsmbmJzcDtQbGVh c2UgbGV0IG1lIHlvdXIgb3BpbmlvbiBvbiB0aGlzIGNsb3N1cmUuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhh bmtzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UGFydGhhPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBKdXN0aW4gVWJlcnRpIFttYWlsdG86 PGEgaHJlZj0ibWFpbHRvOmp1YmVydGlAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmp1YmVy dGlAZ29vZ2xlLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgRmVicnVhcnkg MTQsIDIwMTIgNzoyOSBQTTxicj4NCjxiPlRvOjwvYj4gUmF2aW5kcmFuLCBQYXJ0aGFzYXJhdGhp PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+cnRjd2ViQGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOnB1YmxpYy13ZWJy dGNAdzMub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpwdWJsaWMtd2VicnRjQHczLm9yZzwvYT48YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFNpbmdsZSBvZmZlciB3aXRoIG11bHRpcGxlIGFuc3dlciBo YW5kbGluZyBpbiBKU0VQIFt3YXMgUkU6IFtydGN3ZWJdIE5ldyBKU0VQIGRyYWZ0IHBvc3RlZF08 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5SZWdhcmRpbmcgeW91ciBwcmV2aW91cyBtYWlsLCBhbiBBTlNXRVIgYWZ0ZXIgYW4g QU5TV0VSIHdvdWxkIGVpdGhlciBmYWlsIChpZiB3ZSB3YW50ZWQgdG8gc2ltcGxpZnkpLCBvciBy ZXBsYWNlIHRoZSBwcmV2aW91cyBBTlNXRVIgKGVzc2VudGlhbGx5IHRoZSBzYW1lIGFzIGlmIHlv dSBoYWQgZG9uZSBzZXRMb2NhbERlc2NyaXB0aW9uKE9GRkVSLA0KIGxvY2FsRGVzY3JpcHRpb24p IGZvbGxvd2VkIGJ5IHNldFJlbW90ZURlc2NyaXB0aW9uKEFOU1dFUiwgYW5zd2VyMikuPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SW4gbm8gY2FzZSB3 b3VsZCBpdCBtaXggdGhlIGRlc2NyaXB0aW9ucy9tZWRpYSBmcm9tIGJvdGggYW5zd2Vycy48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPk90aGVyIGNv bW1lbnRzIGlubGluZSBiZWxvdy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPk9uIFR1ZSwgRmViIDE0LCAyMDEyIGF0IDE6MjQgQU0sIFJhdmluZHJhbiwgUGFy dGhhc2FyYXRoaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnByYXZpbmRyYW5Ac29udXNuZXQuY29tIiB0 YXJnZXQ9Il9ibGFuayI+cHJhdmluZHJhbkBzb251c25ldC5jb208L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgSnVzdGluLDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkFkZGluZyB0byBteSBlYXJsaWVyIG1haWwsIEluIGNhc2UgYW5zd2VyMiBTRFAgaXMgdXBk YXRlZCBpbiBvZmZlcmVyMSBicm93c2VyIHdpdGhvdXQgbm90aWZ5aW5nIGFuc3dlcmVyMSwNCiB0 aGVuIGFuc3dlcjEgd2lsbCBjb250aW51ZSB0byB0cmFuc21pdCBSVFAgd2hpY2ggbWF5IG5vdCBi ZSBkZXNpcmVkIGJlaGF2aW9yLiBJTU8sIHdlIG5lZWQgdG8gZGVmaW5lIHRoaXMgYmVoYXZpb3Ig Y2xlYXJseSBpbiBvZmZlcmVyIHNpZGUuIFNvbWUgb2YgdGhlIHBvc3NpYmxlIHNvbHV0aW9ucyBh cmU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGlu O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cD48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+MSk8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+b2ZmZXJlcjEg aGFzIHRvIHNlbmQgYXRsZWFzdCBSVENQIEJZRSBwYWNrZXRzIHRvd2FyZHMgYW5zd2VyZXIxIHdo aWxlIGFjY2VwdGluZyB0aGUgYW5zd2VyZXIyIFNEUC4mbmJzcDsNCjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4yKTwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5UaHJvdyBjYWxsYmFjayB0byBjbGVhciBhbnN3ZXIxIFNEUCB0b3dh cmRzIG9mZmVyZXJKUy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSBhcHBsaWNh dGlvbiB3aGljaCBjYWxsZWQgc2V0UmVtb3RlRGVzY3JpcHRpb24gdHdpY2Ugc2hvdWxkIGhhdmUg dGhlIGJlc3QgaWRlYSBhYm91dCB3aGF0IGlzIGdvaW5nIG9uLCBhbmQgdGhlcmVmb3JlIGlzIHJl c3BvbnNpYmxlIGZvciBub3RpZnlpbmcgYW5zd2VyZXIxIHRoYXQgaXRzIGFuc3dlciBoYXMNCiBi ZWVuIGRpc2NhcmRlZCwgaWYgaXQgbWFrZXMgc2Vuc2UgdG8gZG8gc28uIE5vIGNhbGxiYWNrIHNo b3VsZCBiZSBuZWVkZWQgaGVyZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4N CjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UGxlYXNlIGxldCBtZSBrbm93IHlv dXIgb3BpbmlvbiBoZXJlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rczwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPlBhcnRoYQ0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiBSYXZpbmRyYW4sIFBhcnRoYXNhcmF0aGkNCjxicj4NCjxiPlNlbnQ6PC9i PiBUdWVzZGF5LCBGZWJydWFyeSAxNCwgMjAxMiAxMjowNyBBTTxicj4NCjxiPlRvOjwvYj4gJ0p1 c3RpbiBVYmVydGknOyA8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+cnRjd2ViQGlldGYub3JnPC9hPjsNCjxhIGhyZWY9Im1haWx0bzpwdWJsaWMtd2VicnRj QHczLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnB1YmxpYy13ZWJydGNAdzMub3JnPC9hPjxicj4NCjxi PlN1YmplY3Q6PC9iPiBTaW5nbGUgb2ZmZXIgd2l0aCBtdWx0aXBsZSBhbnN3ZXIgaGFuZGxpbmcg aW4gSlNFUCBbd2FzIFJFOiBbcnRjd2ViXSBOZXcgSlNFUCBkcmFmdCBwb3N0ZWRdPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIEp1c3Rpbiw8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5JbiB0aGUgZHJhZnQsIGl0IGlzIG5vdCBzcGVsbGVkIG91dCBleHBsaWNpdGx5 IHdoYXQgaXMgdGhlIGV4cGVjdGVkIGJlaGF2aW9yIGluIG9mZmVyZXIgYnJvd3NlciBpbg0KIGNh c2UgbXVsdGlwbGUgYW5zd2VyIGlzIHJlY2VpdmVkIGZvciBzaW5nbGUgb2ZmZXIuIE9mZmVyL2Fu c3dlciBleGNoYW5nZSBpbiBvZmZlcmVyIGlzIGFzIGZvbGxvd3M6PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHByZT5PZmZlcmVy SlMtJmd0O09mZmVyZXJVQTogdmFyIG9mZmVyID0gcGMuY3JlYXRlT2ZmZXIobnVsbCk7PG86cD48 L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPk9mZmVyZXJKUy0m Z3Q7T2ZmZXJlclVBOiBwYy5zZXRMb2NhbERlc2NyaXB0aW9uKFNEUF9PRkZFUiwgb2ZmZXIpOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwcmU+T2ZmZXJlckpTLSZndDtPZmZlcmVyVUE6Jm5ic3A7 IHBjLnNldFJlbW90ZURlc2NyaXB0aW9uKFNEUF9BTlNXRVIsIGFuc3dlcjEpOzxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPk9mZmVyZXJVQS0mZ3Q7QW5zd2VyZXIxVUE6ICZsdDttZWRpYSZndDs8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT5PZmZlcmVySlMtJmd0O09mZmVyZXJVQTombmJzcDsgcGMuc2V0 UmVtb3RlRGVzY3JpcHRpb24oU0RQX0FOU1dFUiwgYW5zd2VyMik7PG86cD48L286cD48L3ByZT4N CjxwcmU+T2ZmZXJlclVBLSZndDtBbnN3ZXJlcj9VQTogJmx0O21lZGlhJmd0Oz88bzpwPjwvbzpw PjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IOKAnGFuc3dl cjLigJ0gd2lsbCB1cGRhdGUg4oCcYW5zd2VyMeKAnSBpbiBicm93c2VyIGFuZCBzdGFydGluZyBz ZW5kaW5nL3JlY2VpdmluZw0KIG1lZGlhIHRvd2FyZHMgYW5zd2VyMiBtZWRpYSBJUCBhbmQgcG9y dC4gQ291bGQgeW91IHBsZWFzZSBleHBsYWluIHRoZSBleHBlY3RlZCBiZWhhdmlvciBpbiBvZmZl cmVyIGJyb3dzZXIgd2hldGhlciBpdCB1cGRhdGVzIHRoZSBtZWRpYSBzdHJlYW0gYmFzZWQgb24g dGhlIGxhc3QgYW5zd2VyIG9yIG1peGVzIGJvdGggYW5zd2VyZXIuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhh bmtzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UGFydGhhPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KPGEgaHJlZj0ibWFpbHRvOnJ0Y3dl Yi1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cnRjd2ViLWJvdW5jZXNAaWV0Zi5v cmc8L2E+IFs8YSBocmVmPSJtYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5tYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxm IE9mIDwvYj5KdXN0aW4gVWJlcnRpPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBGZWJydWFy eSAwOSwgMjAxMiAyOjI3IEFNPGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86cnRjd2Vi QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cnRjd2ViQGlldGYub3JnPC9hPjsgPGEgaHJlZj0i bWFpbHRvOnB1YmxpYy13ZWJydGNAdzMub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpwdWJsaWMtd2Vi cnRjQHczLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW3J0Y3dlYl0gTmV3IEpTRVAgZHJh ZnQgcG9zdGVkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPk5vdyBhdmFpbGFibGUgYXQNCjxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJh ZnQtdWJlcnRpLXJ0Y3dlYi1qc2VwLTAxLnR4dCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL3d3 dy5pZXRmLm9yZy9pZC9kcmFmdC11YmVydGktcnRjd2ViLWpzZXAtMDEudHh0PC9hPjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkluY2x1ZGVzIGNoYW5n ZXMgYmFzZWQgb24gaW1wbGVtZW50YXRpb24gZmVlZGJhY2ssIGFuZCBJIGJlbGlldmUgaXQgYWRk cmVzc2VzIG1vc3Qgb2YgdGhlIGNvbmNlcm5zIHJhaXNlZCBpbiBsYXN0IHdlZWsncyBpbnRlcmlt IG1lZXRpbmdzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4tIEluaXRpYWwgZG9jdW1lbnRhdGlvbiBwcm92aWRlZCBmb3IgZWFjaCBBUEkgY2Fs bCwgYW5kIHdoYXQgc3RhdGUgY2hhbmdlcyBpdCBjYXVzZXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LSBNb3JlIGV4YW1wbGVzLCBpbmNsdWRp bmcgYSBjb21wbGV0ZSBiYXNpYyBzYW1wbGUgYXBwbGljYXRpb248bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LSBTaW1wbGlmaWVkIGFwcHJvYWNo IHRvIHRyaWNrbGUgY2FuZGlkYXRlIGhhbmRsaW5nPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0gUmVzb2x2ZWQgY29uY2VybnMgYWJvdXQgaG93 IHRvIHNlcGFyYXRlIFNEUCBhdHRyaWJ1dGVzIGludG8gbWVkaWEgLyB0cmFuc3BvcnQ8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LSBQcm92aWRl ZCBlbmNhcHN1bGF0aW9uIGZvciBTRFAgYmxvYnMgYW5kIElDRSBjYW5kaWRhdGUgbGluZXMsIGlu IHRoZSBldmVudCB3ZSB3YW50IHRvIGNoYW5nZSBlbmNvZGluZ3Mgb3IgcHJvdmlkZSBoZWxwZXIg ZnVuY3Rpb25zIGZvciBKUzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4tIFByb3ZpZGVkIG1lY2hhbmlzbSBmb3IgbGltaXRpbmcgY2FuZGlkYXRl cyB0byBUVVJOLW9ubHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+LSBSZXNvbHZlZCBzZXZlcmFsIGltcGxlbWVudGF0aW9uIGlzc3VlczxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBo YXZlIG5vdCB5ZXQgYWRkcmVzc2VkIHRoZSBub24tb3ZlcmxhcHBpbmcgY29kZWMgY29uY2VybiBt ZW50aW9uZWQgaW4gdGhlIGludGVyaW0gbWVldGluZy4gSSB0aGluayB0aGVyZSBhcmUgd2F5cyBv ZiBoYW5kbGluZyB0aGlzIGVpdGhlciBpbiB0aGUgYXBwbGljYXRpb24gb3IgdGhlIGltcGxlbWVu dGF0aW9uLA0KIGJ1dCBJIHdhbnRlZCB0byBnZXQgdGhpcyAtMDEgb3V0IGZpcnN0IGZvciBmZWVk YmFjay48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_387F9047F55E8C42850AD6B3A7A03C6C0E03FB7Cinbamail01sonus_-- From harald@alvestrand.no Tue Feb 14 09:24: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 787CF21F8652 for ; Tue, 14 Feb 2012 09:24:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.504 X-Spam-Level: X-Spam-Status: No, score=-110.504 tagged_above=-999 required=5 tests=[AWL=0.094, 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 jSBI7sKFy2UE for ; Tue, 14 Feb 2012 09:24:13 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7F921F85E7 for ; Tue, 14 Feb 2012 09:24:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 46FCD39E113; Tue, 14 Feb 2012 18:24:12 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id akIrjZyeYkRL; Tue, 14 Feb 2012 18:24:08 +0100 (CET) Received: from hta-dell.lul.corp.google.com (unknown [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 414C339E10E; Tue, 14 Feb 2012 18:24:08 +0100 (CET) Message-ID: <4F3A98B7.2080704@alvestrand.no> Date: Tue, 14 Feb 2012 18:24:07 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.26) Gecko/20120131 Thunderbird/3.1.18 MIME-Version: 1.0 To: Justin Uberti References: <29CD92BB-6764-4B87-AA99-ADB4B9685059@iii.ca> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040209080608020800090202" Cc: rtcweb@ietf.org Subject: Re: [rtcweb] What parts of SDP need to changeable by the JSapplication 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, 14 Feb 2012 17:24:14 -0000 This is a multi-part message in MIME format. --------------040209080608020800090202 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 02/14/2012 05:40 PM, Justin Uberti wrote: > > > On Tue, Feb 14, 2012 at 5:41 AM, Jim Barnett > > wrote: > > In the rehydration case, much of what the JS is supplying are > values that the browser initially generated (but lost on page > reload), so it’s not really _/changing/_ those values. The > underlying question is: which parts of the SDP can the JS change > to something other than what the browser initially provided? > > > As a start, I think the JS should be able to: > - remove or reorder codecs (m=) > - change codec attributes, if it makes sense (a=fmtp; Partha also > mentioned ptime) > - enable/disable BUNDLE (a=group) > - enable/disable RTCP mux (a=rtcp-mux) > - reorder SRTP crypto-suites (a=crypto) > - change SRTP parameters or keys (a=crypto) > - change send resolution or framerate (TBD) > - change desired recv resolution or framerate (TBD) > - change total bandwidth (b=) > - remove desired AVPF mechanisms (a=rtcp-fb) > - remove RTP header extensions (a=rtphdr-ext) > - add/change SSRC grouping (e.g. FID, RTX, etc) (a=ssrc-group) > - add SSRC attributes (a=ssrc) > - change ICE ufrag/password (a=ice-ufrag/pwd) > - change media send/recv state (a=sendonly/recvonly/inactive) > > The JS must inform the browser of most of these changes in order for > them to work correctly. (Reordering codecs is one that could be done > by JS without the browser knowing.) reordering m= lines has to be messaged to the browser, since it depends on the order to correlate m= lines in an answer with the offer. reordering the list of codecs in the end of the m= line should also be signalled to the browser, I think; it might affect which codecs it starts using when it sends, I think (for the case where the respondent supports multiple codecs). > > -Jim > > *From:*rtcweb-bounces@ietf.org > [mailto:rtcweb-bounces@ietf.org ] > *On Behalf Of *Justin Uberti > *Sent:* Monday, February 13, 2012 10:30 PM > *To:* Cullen Jennings > *Cc:* rtcweb@ietf.org > > > *Subject:* Re: [rtcweb] What parts of SDP need to changeable by > the JSapplication > > We've had cases where we've needed to change the codec payload > types, codec parameters (e.g. bitrate), and SRTP keys. > > For the rehydration use case, you really need to be able to supply > just about everything though. > > On Mon, Feb 13, 2012 at 10:19 AM, Cullen Jennings > wrote: > > > I'd like to figure out what parts of the SDP that the JS App needs > to be able to change. > > The one clear example I have heard is removing a codec that the > App does not want to use. > > Are there others? > _______________________________________________ > 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 --------------040209080608020800090202 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit On 02/14/2012 05:40 PM, Justin Uberti wrote:


On Tue, Feb 14, 2012 at 5:41 AM, Jim Barnett <Jim.Barnett@genesyslab.com> wrote:

In the rehydration case, much of what the JS is supplying are values that the browser initially generated (but lost on page reload), so it’s not really _changing_ those values.  The underlying question is: which parts of the SDP can the JS change to something other than what the browser initially provided?


As a start, I think the JS should be able to:
- remove or reorder codecs (m=)
- change codec attributes, if it makes sense (a=fmtp; Partha also mentioned ptime)
- enable/disable BUNDLE (a=group)
- enable/disable RTCP mux (a=rtcp-mux)
- reorder SRTP crypto-suites (a=crypto)
- change SRTP parameters or keys (a=crypto)
- change send resolution or framerate (TBD)
- change desired recv resolution or framerate (TBD)
- change total bandwidth (b=)
- remove desired AVPF mechanisms (a=rtcp-fb)
- remove RTP header extensions (a=rtphdr-ext)
- add/change SSRC grouping (e.g. FID, RTX, etc) (a=ssrc-group)
- add SSRC attributes (a=ssrc)
- change ICE ufrag/password (a=ice-ufrag/pwd)
- change media send/recv state (a=sendonly/recvonly/inactive)

The JS must inform the browser of most of these changes in order for them to work correctly. (Reordering codecs is one that could be done by JS without the browser knowing.)
reordering m= lines has to be messaged to the browser, since it depends on the order to correlate m= lines in an answer with the offer.

reordering the list of codecs in the end of the m= line should also be signalled to the browser, I think; it might affect which codecs it starts using when it sends, I think (for the case where the respondent supports multiple codecs).


 

-          Jim

 

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Justin Uberti
Sent: Monday, February 13, 2012 10:30 PM
To: Cullen Jennings
Cc: rtcweb@ietf.org


Subject: Re: [rtcweb] What parts of SDP need to changeable by the JSapplication

 

We've had cases where we've needed to change the codec payload types, codec parameters (e.g. bitrate), and SRTP keys.

 

For the rehydration use case, you really need to be able to supply just about everything though.

On Mon, Feb 13, 2012 at 10:19 AM, Cullen Jennings <fluffy@iii.ca> wrote:


I'd like to figure out what parts of the SDP that the JS App needs to be able to change.

The one clear example I have heard is removing a codec that the App does not want to use.

Are there others?
_______________________________________________
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

--------------040209080608020800090202-- From juberti@google.com Tue Feb 14 10:05: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 3F2DF21E807E for ; Tue, 14 Feb 2012 10:05:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.722 X-Spam-Level: X-Spam-Status: No, score=-102.722 tagged_above=-999 required=5 tests=[AWL=0.254, 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 a7qxH0sqMzXj for ; Tue, 14 Feb 2012 10:05:56 -0800 (PST) Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 74DC021E8027 for ; Tue, 14 Feb 2012 10:05:56 -0800 (PST) Received: by qan41 with SMTP id 41so439324qan.10 for ; Tue, 14 Feb 2012 10:05:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=mVLPi7+Nf1wlO3tDt/0PRtgjcbtU91UP+2+W3It6inE=; b=YulF13zzC5QqP6wDfSOsBBl5XVoPAZHC9GZlOfbMm2kLPU7NjXjsXhXQ5BlvFICAlo dA900rBTLD6PAJRw8i2u5NhaFrHIVR7bDzdW7sghNu7IM0SWZoXUX0FKebHnNbHVAUVQ E4cspaap6I+TzMdf36lorNevJe6YB+Wmrb42Q= Received: by 10.229.106.221 with SMTP id y29mr12894215qco.88.1329242755901; Tue, 14 Feb 2012 10:05:55 -0800 (PST) Received: by 10.229.106.221 with SMTP id y29mr12894200qco.88.1329242755647; Tue, 14 Feb 2012 10:05:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.45.213 with HTTP; Tue, 14 Feb 2012 10:05:35 -0800 (PST) In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E03FB7C@inba-mail01.sonusnet.com> References: <387F9047F55E8C42850AD6B3A7A03C6C0E03F8A4@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E03FAB5@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E03FB7C@inba-mail01.sonusnet.com> From: Justin Uberti Date: Tue, 14 Feb 2012 13:05:35 -0500 Message-ID: To: "Ravindran, Parthasarathi" Content-Type: multipart/alternative; boundary=002354470f6c454b3804b8f0723d X-System-Of-Record: true X-Gm-Message-State: ALoCoQn1JbjUAQiOzpsZGkctykl/3uCJrKXRKkNrLFSH17fisg3g7u6GP2jjK32dGXqjFL76IC0OGS7b9mkmN0p8xNSAj1l3gt/oVe4dFzaybkdG9uClQRasKkmhgoOPSgHLdtMh/TUUb1tawMP+bpIqreIhT5L5Sw== Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] Single offer with multiple answer handling in JSEP [was RE: New JSEP draft posted] 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, 14 Feb 2012 18:05:58 -0000 --002354470f6c454b3804b8f0723d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Partha, I need more information about the use case to provide an accurate response. As mentioned in my earlier mail, are both answers 2xx responses? On Tue, Feb 14, 2012 at 12:17 PM, Ravindran, Parthasarathi < pravindran@sonusnet.com> wrote: > Hi Justin,**** > > ** ** > > In this mail thread, Let us define the behavior of multiple (atleast two) > answers for the single offer in WebRTC browser. Now, Please let me know > your opinion for my below mail.**** > > ** ** > > Thanks**** > > Partha**** > > ** ** > > *From:* Justin Uberti [mailto:juberti@google.com] > *Sent:* Tuesday, February 14, 2012 9:47 PM > > *To:* Ravindran, Parthasarathi > *Cc:* rtcweb@ietf.org; public-webrtc@w3.org > *Subject:* Re: Single offer with multiple answer handling in JSEP [was > RE: [rtcweb] New JSEP draft posted]**** > > ** ** > > ** ** > > On Tue, Feb 14, 2012 at 6:39 AM, Ravindran, Parthasarathi < > pravindran@sonusnet.com> wrote:**** > > Hi Justin,**** > > **** > > It will be good to mention in the JSEP draft that multiple answers for > single offer will not lead to RTP Mixing and WebRTC client acts as RTP > Endpoint. **** > > **** > > Failing the second Answer will be limiting the provision in RFC 3264 > offer/answer itself as RFC 3264 supports single offer with multiple answe= r. > Also, it is better to define the behavior in API rather than putting this > scenario in the browser implementation specific. In simple scenarios (lik= e > alerting with one answer, connect with second answer), replacing the > previous ANSWER will be expected behavior. This may not be desired behavi= or > in case two connect responses from different WebRTC clients received with > different answers but there is no other alternative solution possible > without mixing.**** > > ** ** > > Do you need to support 2 final answers, or would the provisional answer > support provided via SDP_PRANSWER work for you?**** > > **** > > IMO, it is better to define it explicitly in JSEP that =E2=80=9Clatest AN= SWER to > the offer will replace the existing answer is the expected behavior =E2= =80=9D. > Also, Please mentioned that JS application is responsible for discarding > (terminating) previous ANSWER notification. Please let me your opinion = on > this closure.**** > > **** > > Thanks**** > > Partha**** > > **** > > *From:* Justin Uberti [mailto:juberti@google.com] > *Sent:* Tuesday, February 14, 2012 7:29 PM > *To:* Ravindran, Parthasarathi > *Cc:* rtcweb@ietf.org; public-webrtc@w3.org > *Subject:* Re: Single offer with multiple answer handling in JSEP [was > RE: [rtcweb] New JSEP draft posted]**** > > **** > > Regarding your previous mail, an ANSWER after an ANSWER would either fail > (if we wanted to simplify), or replace the previous ANSWER (essentially t= he > same as if you had done setLocalDescription(OFFER, localDescription) > followed by setRemoteDescription(ANSWER, answer2).**** > > **** > > In no case would it mix the descriptions/media from both answers.**** > > **** > > Other comments inline below.**** > > On Tue, Feb 14, 2012 at 1:24 AM, Ravindran, Parthasarathi < > pravindran@sonusnet.com> wrote:**** > > Hi Justin,**** > > **** > > Adding to my earlier mail, In case answer2 SDP is updated in offerer1 > browser without notifying answerer1, then answer1 will continue to transm= it > RTP which may not be desired behavior. IMO, we need to define this behavi= or > clearly in offerer side. Some of the possible solutions are**** > > **** > > 1) offerer1 has to send atleast RTCP BYE packets towards answerer1 > while accepting the answerer2 SDP. **** > > 2) Throw callback to clear answer1 SDP towards offererJS.**** > > **** > > The application which called setRemoteDescription twice should have the > best idea about what is going on, and therefore is responsible for > notifying answerer1 that its answer has been discarded, if it makes sense > to do so. No callback should be needed here. **** > > **** > > Please let me know your opinion here.**** > > **** > > Thanks**** > > Partha **** > > **** > > *From:* Ravindran, Parthasarathi > *Sent:* Tuesday, February 14, 2012 12:07 AM > *To:* 'Justin Uberti'; rtcweb@ietf.org; public-webrtc@w3.org > *Subject:* Single offer with multiple answer handling in JSEP [was RE: > [rtcweb] New JSEP draft posted]**** > > **** > > Hi Justin,**** > > **** > > In the draft, it is not spelled out explicitly what is the expected > behavior in offerer browser in case multiple answer is received for singl= e > offer. Offer/answer exchange in offerer is as follows:**** > > **** > > OffererJS->OffererUA: var offer =3D pc.createOffer(null);**** > > OffererJS->OffererUA: pc.setLocalDescription(SDP_OFFER, offer);**** > > OffererJS->OffererUA: pc.setRemoteDescription(SDP_ANSWER, answer1);**** > > OffererUA->Answerer1UA: **** > > OffererJS->OffererUA: pc.setRemoteDescription(SDP_ANSWER, answer2);**** > > OffererUA->Answerer?UA: ?**** > > **** > > My understanding is that =E2=80=9Canswer2=E2=80=9D will update =E2=80=9Ca= nswer1=E2=80=9D in browser and > starting sending/receiving media towards answer2 media IP and port. Could > you please explain the expected behavior in offerer browser whether it > updates the media stream based on the last answer or mixes both answerer.= * > *** > > **** > > Thanks**** > > Partha**** > > **** > > *From:* rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] > *On Behalf Of *Justin Uberti > *Sent:* Thursday, February 09, 2012 2:27 AM > *To:* rtcweb@ietf.org; public-webrtc@w3.org > *Subject:* [rtcweb] New JSEP draft posted**** > > **** > > Now available at http://www.ietf.org/id/draft-uberti-rtcweb-jsep-01.txt**= * > * > > **** > > Includes changes based on implementation feedback, and I believe it > addresses most of the concerns raised in last week's interim meetings:***= * > > - Initial documentation provided for each API call, and what state change= s > it causes**** > > - More examples, including a complete basic sample application**** > > - Simplified approach to trickle candidate handling**** > > - Resolved concerns about how to separate SDP attributes into media / > transport**** > > - Provided encapsulation for SDP blobs and ICE candidate lines, in the > event we want to change encodings or provide helper functions for JS**** > > - Provided mechanism for limiting candidates to TURN-only**** > > - Resolved several implementation issues**** > > **** > > I have not yet addressed the non-overlapping codec concern mentioned in > the interim meeting. I think there are ways of handling this either in th= e > application or the implementation, but I wanted to get this -01 out first > for feedback.**** > > **** > > ** ** > --002354470f6c454b3804b8f0723d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Partha,

I need more information about the use case to pr= ovide an accurate response. As mentioned in my earlier mail, are both answe= rs 2xx responses?

On Tue, Feb 14, 2012 at= 12:17 PM, Ravindran, Parthasarathi <pravindran@sonusnet.com> wrote:

Hi Justin,<= /span>

=C2=A0

In this mail thread, Let = us define the behavior of multiple (atleast two) answers for the single off= er in WebRTC browser. =C2=A0Now, Please let me know your opinion for my below mail.

=C2=A0

Thanks

Partha

=C2=A0

From: Justin U= berti [mailto:juber= ti@google.com]
Sent: Tuesday, February 14, 2012 9:47 PM


To: Ravindran, Parthasarathi
Cc: rtcweb@ietf= .org; public-= webrtc@w3.org
Subject: Re: Single offer with multiple answer handling in JSEP [was= RE: [rtcweb] New JSEP draft posted]

=C2=A0

=C2=A0<= /p>

On Tue, Feb 14, 2012 at 6:39 AM, Ravindran, Parthasa= rathi <prav= indran@sonusnet.com> wrote:

Hi Justin,<= u>

=C2=A0

It will be good to mentio= n in the JSEP draft =C2=A0that multiple answers for single offer will not l= ead to RTP Mixing and WebRTC client acts as RTP Endpoint.

=C2=A0

Failing the second Answer= will be limiting the provision in RFC 3264 offer/answer itself as RFC 3264 supports single offer with multiple answer. Also, it is better to define t= he behavior in API rather than putting this scenario in the browser impleme= ntation specific. In simple scenarios (like alerting with one answer, conne= ct with second answer), replacing the previous ANSWER will be expected behavior. This may not be desired beh= avior in case two connect responses from different WebRTC clients received = with different answers =C2=A0but there is no other alternative solution pos= sible without mixing.

=C2=A0

Do you need to support 2 final answers, or would the= provisional answer support provided via SDP_PRANSWER work for you?<= u>

=C2=A0

IMO, it is better to defi= ne it explicitly in JSEP that =E2=80=9Clatest ANSWER to the offer will repl= ace the existing answer is the expected behavior =E2=80=9D. Also, Please mentioned= that JS application is responsible for discarding (terminating) previous A= NSWER notification. =C2=A0=C2=A0Please let me your opinion on this closure.=

=C2=A0

Thanks

Partha

=C2=A0

From: Justin U= berti [mailto:juber= ti@google.com]
Sent: Tuesday, February 14, 2012 7:29 PM
To: Ravindran, Parthasarathi
Cc: rtcweb@ietf= .org; public-webrtc@w3.org
Subject: Re: Single offer with multiple answer handling in JSEP [was= RE: [rtcweb] New JSEP draft posted]

=C2=A0

Regarding your previous mail, an ANSWER after an ANS= WER would either fail (if we wanted to simplify), or replace the previous A= NSWER (essentially the same as if you had done setLocalDescription(OFFER, localDescription) followed by setRemoteDescription(ANSWER, answer2).

=C2=A0

In no case would it mix the descriptions/media from = both answers.

=C2=A0

Other comments inline= below.

On Tue, Feb 14, 2012 at 1:24 AM, Ravindran, Parthasa= rathi <prav= indran@sonusnet.com> wrote:

Hi Justin,<= u>

=C2=A0

Adding to my earlier mail= , In case answer2 SDP is updated in offerer1 browser without notifying answ= erer1, then answer1 will continue to transmit RTP which may not be desired behavi= or. IMO, we need to define this behavior clearly in offerer side. Some of t= he possible solutions are

=C2=A0

1)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 offerer1 has to send atleast RTCP BYE pac= kets towards answerer1 while accepting the answerer2 SDP.=C2=A0

2)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Throw callback to clear answer1 SDP towar= ds offererJS.

=C2=A0

The application which called setRemoteDescription tw= ice should have the best idea about what is going on, and therefore is resp= onsible for notifying answerer1 that its answer has been discarded, if it makes sense to do so. No callback should be needed h= ere.=C2=A0

=C2=A0

Please let me know your o= pinion here.

=C2=A0

Thanks

Partha

=C2=A0

From: Ravindra= n, Parthasarathi
Sent: Tuesday, February 14, 2012 12:07 AM
To: 'Justin Uberti'; rtcweb@ietf.org; public-webrtc@w3.= org
Subject: Single offer with multiple answer handling in JSEP [was RE:= [rtcweb] New JSEP draft posted]

=C2=A0

Hi Justin,<= u>

=C2=A0

In the draft, it is not s= pelled out explicitly what is the expected behavior in offerer browser in case multiple answer is received for single offer. Offer/answer exchange i= n offerer is as follows:

=C2=A0

OffererJS->OffererUA: var offer =3D pc.createOffer(null);=

OffererJS->OffererUA: pc.setLocalDescription(SDP_OFFER,= offer);

OffererJS->OffererUA:=C2=A0 pc.setRemoteDescription(SDP_ANSWER, ans=
wer1);
OffererUA->Answerer1UA: <media>
OffererJS->OffererUA:=C2=A0 pc.setRemoteDescription(SDP_ANSWER, ans=
wer2);
OffererUA->Answerer?UA: <media>?

=C2=A0

My understanding is that = =E2=80=9Canswer2=E2=80=9D will update =E2=80=9Canswer1=E2=80=9D in browser = and starting sending/receiving media towards answer2 media IP and port. Could you please explain the expe= cted behavior in offerer browser whether it updates the media stream based = on the last answer or mixes both answerer.

=C2=A0

Thanks

Partha

=C2=A0

From: rtcweb-bounces= @ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Justin Uberti
Sent: Thursday, February 09, 2012 2:27 AM
To: rtcweb@ietf= .org; public-webrtc@w3.org
Subject: [rtcweb] New JSEP draft posted

=C2=A0

Now available at http://www.ietf.org/id/draft-uberti-rtcweb-jsep-01.txt

=C2=A0

Includes changes based on implementation feedback, a= nd I believe it addresses most of the concerns raised in last week's in= terim meetings:

- Initial documentation provided for each API call, = and what state changes it causes

- More examples, including a complete basic sample a= pplication

- Simplified approach to trickle candidate handling<= u>

- Resolved concerns about how to separate SDP attrib= utes into media / transport

- Provided encapsulation for SDP blobs and ICE candi= date lines, in the event we want to change encodings or provide helper func= tions for JS

- Provided mechanism for limiting candidates to TURN= -only

- Resolved several implementation issues

=C2=A0

I have not yet addressed the non-overlapping codec c= oncern mentioned in the interim meeting. I think there are ways of handling= this either in the application or the implementation, but I wanted to get this -01 out first for feedback.

=C2=A0

=C2=A0


--002354470f6c454b3804b8f0723d-- From pravindran@sonusnet.com Tue Feb 14 11:24: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 AD47621F86B9 for ; Tue, 14 Feb 2012 11:24:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IgHGKy3lmqk5 for ; Tue, 14 Feb 2012 11:24:31 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 9B69321F8559 for ; Tue, 14 Feb 2012 11:24:30 -0800 (PST) Received: from sonusmail07.sonusnet.com (sonusmail07.sonusnet.com [10.128.32.157]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q1EJPFRv010308; Tue, 14 Feb 2012 14:25:15 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Feb 2012 14:24:27 -0500 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 15 Feb 2012 00:54:35 +0530 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, 15 Feb 2012 00:54:34 +0530 From: "Ravindran, Parthasarathi" To: Justin Uberti Thread-Topic: Single offer with multiple answer handling in JSEP [was RE: [rtcweb] New JSEP draft posted] Thread-Index: AQHM6uFaIZmsOFGRck2Q3yR4wFD2TJY8D6WAgABfAXD//8edAIAAZLcQ//+5j4CAAGW5MA== Date: Tue, 14 Feb 2012 19:24:34 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E03FC20@inba-mail01.sonusnet.com> References: <387F9047F55E8C42850AD6B3A7A03C6C0E03F8A4@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E03FAB5@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E03FB7C@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: [121.242.142.186] Content-Type: multipart/alternative; boundary="_000_387F9047F55E8C42850AD6B3A7A03C6C0E03FC20inbamail01sonus_" MIME-Version: 1.0 X-OriginalArrivalTime: 14 Feb 2012 19:24:35.0718 (UTC) FILETIME=[4954EA60:01CCEB4E] Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] Single offer with multiple answer handling in JSEP [was RE: New JSEP draft posted] 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, 14 Feb 2012 19:24:32 -0000 --_000_387F9047F55E8C42850AD6B3A7A03C6C0E03FC20inbamail01sonus_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SnVzdGluLA0KDQpTb21lIG9mIHRoZSB1c2VjYXNlcyBjb3VsZCBiZQ0KDQoxKSAgICAgIFRoZSBz YW1lIHVzZXIgb2YgYSB3ZWJzaXRlIHNpZ25lZC1pbiBpbiB0aGUgbXVsdGlwbGVzIGRldmljZXMg YW5kIGFjdHMgYXMgYW5zd2VyZXIsICB0aGUgc2Vzc2lvbiBlc3RhYmxpc2htZW50IHJlcXVlc3Qg dG8gdGhlIGlkZW50aXR5IHdpbGwgYWxlcnQgYWxsIHRoZSBzaWduZWQtaW4gZGV2aWNlcyBhbmQg aXQgaXMgcG9zc2libGUgdGhhdCBtdWx0aXBsZSBkZXZpY2VzIGFuc3dlciB0byB0aGUgc2Vzc2lv bi4gSGVyZSwgdXNlciBtYXkgbW92ZSBmcm9tIG9uZSBkZXZpY2UgKG1vYmlsZSkgdG8gYW5vdGhl ciBkZXZpY2UgKGRlc2t0b3ApIHdpdGhpbiB0aGUgc2Vzc2lvbiBhbmQgd2lzaGVzIHRvIGNvbnRp bnVlIHRoZSBzZXNzaW9uIHdpdGggdGhlIGxhc3QgYW5zd2VyLiBQbGVhc2Ugbm90ZSB0aGF0IHdl YnNpdGUgaXMgZmxleGlibGUgdG8gcHJvdmlkZSB0aGlzIHNlcnZpY2UuDQoNCjIpICAgICAgUkZD IDMyNjEgU0lQIFVBIG9mZmVyL2Fuc3dlciBoYW5kbGluZyB3LnIudCBJTlZJVEUgd2l0aCBTRFAg dG8gbXVsdGlwbGUgMnh4IHdpdGggU0RQIGhhbmRsaW5nIHNjZW5hcmlvIHVzaW5nIEpTRVANCg0K MykgICAgICBBbm90aGVyIFNJUCB1c2VjYXNlIGNvdWxkIGJlIG11bHRpcGxlIDE4eCByZXNwb25z ZXMgd2l0aCBTRFAgZm9yIElOVklURSB3aXRoIFNEUCBhbmQgbXVsdGlwbGUgMnh4IHJlc3BvbnNl cyB3aXRob3V0IFNEUCBidXQgb3JkZXIgd2l0aGluIDE4eCBhbmQgMjAwIGFyZSBub3Qgc2FtZS4g U2F5IDJ4eCBvZiB0aGUgc2Vjb25kIDE4eCBpcyByZWNlaXZlZCBhcyB0aGUgZmlyc3QgMnh4LiBI ZXJlLCB3ZSBuZWVkIHRvIGtub3cgaG93IHNlY29uZCAxOHggaXMgaGFuZGxlZCBhbmQgYWxzbywg dGhlIHN1YnNlcXVlbnQgMnh4IGlzIGhhbmRsZWQuDQoNCk9mIGNvdXJzZSwgaXQgaXMgcG9zc2li bGUgdG8gYnVpbGQgbW9yZSB1c2VjYXNlcyBhcm91bmQgdGhpcyBhcmVhLiBBcyB3ZSBtYWRlIHNp Z25hbGluZyBvdXRzaWRlIHRoZSBzY29wZSBvZiBXZWJSVEMsIGl0IGlzIHVwdG8gSlMgYXBwbGlj YXRpb24gdG8gZGVjaWRlIHRoZSBvcmRlciBpbiB3aGljaCBvZmZlci9hbnN3ZXIgaGFwcGVucy4g SeKAmW0gbm90IHJlbGF0aW5nIG9mZmVyL2Fuc3dlciBGU00gd2l0aCBzZXNzaW9uIGVzdGFibGlz aG1lbnQgc3RhdGUgbGlrZSAxOHgsIDJ4eCBidXQgSeKAmW0gaW50ZXJlc3RlZCBpbiBrbm93aW5n IGJyb3dzZXIgbWVkaWEgcGxhbmUgYmVoYXZpb3IgaW4gZGlmZmVyZW50IHN0YXRlIG9mIG9mZmVy L2Fuc3dlciBoYW5kbGluZyBieSB3aGljaCBKUyBhcHBsaWNhdGlvbiBiZWhhdmVzIGNvbnNpc3Rl bnRseSBpbiBhbGwgYnJvd3NlcnMuDQoNClRoYW5rcw0KUGFydGhhDQoNCg0KRnJvbTogSnVzdGlu IFViZXJ0aSBbbWFpbHRvOmp1YmVydGlAZ29vZ2xlLmNvbV0NClNlbnQ6IFR1ZXNkYXksIEZlYnJ1 YXJ5IDE0LCAyMDEyIDExOjM2IFBNDQpUbzogUmF2aW5kcmFuLCBQYXJ0aGFzYXJhdGhpDQpDYzog cnRjd2ViQGlldGYub3JnOyBwdWJsaWMtd2VicnRjQHczLm9yZw0KU3ViamVjdDogUmU6IFNpbmds ZSBvZmZlciB3aXRoIG11bHRpcGxlIGFuc3dlciBoYW5kbGluZyBpbiBKU0VQIFt3YXMgUkU6IFty dGN3ZWJdIE5ldyBKU0VQIGRyYWZ0IHBvc3RlZF0NCg0KUGFydGhhLA0KDQpJIG5lZWQgbW9yZSBp bmZvcm1hdGlvbiBhYm91dCB0aGUgdXNlIGNhc2UgdG8gcHJvdmlkZSBhbiBhY2N1cmF0ZSByZXNw b25zZS4gQXMgbWVudGlvbmVkIGluIG15IGVhcmxpZXIgbWFpbCwgYXJlIGJvdGggYW5zd2VycyAy eHggcmVzcG9uc2VzPw0KT24gVHVlLCBGZWIgMTQsIDIwMTIgYXQgMTI6MTcgUE0sIFJhdmluZHJh biwgUGFydGhhc2FyYXRoaSA8cHJhdmluZHJhbkBzb251c25ldC5jb208bWFpbHRvOnByYXZpbmRy YW5Ac29udXNuZXQuY29tPj4gd3JvdGU6DQpIaSBKdXN0aW4sDQoNCkluIHRoaXMgbWFpbCB0aHJl YWQsIExldCB1cyBkZWZpbmUgdGhlIGJlaGF2aW9yIG9mIG11bHRpcGxlIChhdGxlYXN0IHR3bykg YW5zd2VycyBmb3IgdGhlIHNpbmdsZSBvZmZlciBpbiBXZWJSVEMgYnJvd3Nlci4gIE5vdywgUGxl YXNlIGxldCBtZSBrbm93IHlvdXIgb3BpbmlvbiBmb3IgbXkgYmVsb3cgbWFpbC4NCg0KVGhhbmtz DQpQYXJ0aGENCg0KRnJvbTogSnVzdGluIFViZXJ0aSBbbWFpbHRvOmp1YmVydGlAZ29vZ2xlLmNv bTxtYWlsdG86anViZXJ0aUBnb29nbGUuY29tPl0NClNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDE0 LCAyMDEyIDk6NDcgUE0NCg0KVG86IFJhdmluZHJhbiwgUGFydGhhc2FyYXRoaQ0KQ2M6IHJ0Y3dl YkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPjsgcHVibGljLXdlYnJ0Y0B3My5vcmc8 bWFpbHRvOnB1YmxpYy13ZWJydGNAdzMub3JnPg0KU3ViamVjdDogUmU6IFNpbmdsZSBvZmZlciB3 aXRoIG11bHRpcGxlIGFuc3dlciBoYW5kbGluZyBpbiBKU0VQIFt3YXMgUkU6IFtydGN3ZWJdIE5l dyBKU0VQIGRyYWZ0IHBvc3RlZF0NCg0KDQpPbiBUdWUsIEZlYiAxNCwgMjAxMiBhdCA2OjM5IEFN LCBSYXZpbmRyYW4sIFBhcnRoYXNhcmF0aGkgPHByYXZpbmRyYW5Ac29udXNuZXQuY29tPG1haWx0 bzpwcmF2aW5kcmFuQHNvbnVzbmV0LmNvbT4+IHdyb3RlOg0KSGkgSnVzdGluLA0KDQpJdCB3aWxs IGJlIGdvb2QgdG8gbWVudGlvbiBpbiB0aGUgSlNFUCBkcmFmdCAgdGhhdCBtdWx0aXBsZSBhbnN3 ZXJzIGZvciBzaW5nbGUgb2ZmZXIgd2lsbCBub3QgbGVhZCB0byBSVFAgTWl4aW5nIGFuZCBXZWJS VEMgY2xpZW50IGFjdHMgYXMgUlRQIEVuZHBvaW50Lg0KDQpGYWlsaW5nIHRoZSBzZWNvbmQgQW5z d2VyIHdpbGwgYmUgbGltaXRpbmcgdGhlIHByb3Zpc2lvbiBpbiBSRkMgMzI2NCBvZmZlci9hbnN3 ZXIgaXRzZWxmIGFzIFJGQyAzMjY0IHN1cHBvcnRzIHNpbmdsZSBvZmZlciB3aXRoIG11bHRpcGxl IGFuc3dlci4gQWxzbywgaXQgaXMgYmV0dGVyIHRvIGRlZmluZSB0aGUgYmVoYXZpb3IgaW4gQVBJ IHJhdGhlciB0aGFuIHB1dHRpbmcgdGhpcyBzY2VuYXJpbyBpbiB0aGUgYnJvd3NlciBpbXBsZW1l bnRhdGlvbiBzcGVjaWZpYy4gSW4gc2ltcGxlIHNjZW5hcmlvcyAobGlrZSBhbGVydGluZyB3aXRo IG9uZSBhbnN3ZXIsIGNvbm5lY3Qgd2l0aCBzZWNvbmQgYW5zd2VyKSwgcmVwbGFjaW5nIHRoZSBw cmV2aW91cyBBTlNXRVIgd2lsbCBiZSBleHBlY3RlZCBiZWhhdmlvci4gVGhpcyBtYXkgbm90IGJl IGRlc2lyZWQgYmVoYXZpb3IgaW4gY2FzZSB0d28gY29ubmVjdCByZXNwb25zZXMgZnJvbSBkaWZm ZXJlbnQgV2ViUlRDIGNsaWVudHMgcmVjZWl2ZWQgd2l0aCBkaWZmZXJlbnQgYW5zd2VycyAgYnV0 IHRoZXJlIGlzIG5vIG90aGVyIGFsdGVybmF0aXZlIHNvbHV0aW9uIHBvc3NpYmxlIHdpdGhvdXQg bWl4aW5nLg0KDQpEbyB5b3UgbmVlZCB0byBzdXBwb3J0IDIgZmluYWwgYW5zd2Vycywgb3Igd291 bGQgdGhlIHByb3Zpc2lvbmFsIGFuc3dlciBzdXBwb3J0IHByb3ZpZGVkIHZpYSBTRFBfUFJBTlNX RVIgd29yayBmb3IgeW91Pw0KDQpJTU8sIGl0IGlzIGJldHRlciB0byBkZWZpbmUgaXQgZXhwbGlj aXRseSBpbiBKU0VQIHRoYXQg4oCcbGF0ZXN0IEFOU1dFUiB0byB0aGUgb2ZmZXIgd2lsbCByZXBs YWNlIHRoZSBleGlzdGluZyBhbnN3ZXIgaXMgdGhlIGV4cGVjdGVkIGJlaGF2aW9yIOKAnS4gQWxz bywgUGxlYXNlIG1lbnRpb25lZCB0aGF0IEpTIGFwcGxpY2F0aW9uIGlzIHJlc3BvbnNpYmxlIGZv ciBkaXNjYXJkaW5nICh0ZXJtaW5hdGluZykgcHJldmlvdXMgQU5TV0VSIG5vdGlmaWNhdGlvbi4g ICBQbGVhc2UgbGV0IG1lIHlvdXIgb3BpbmlvbiBvbiB0aGlzIGNsb3N1cmUuDQoNClRoYW5rcw0K UGFydGhhDQoNCkZyb206IEp1c3RpbiBVYmVydGkgW21haWx0bzpqdWJlcnRpQGdvb2dsZS5jb208 bWFpbHRvOmp1YmVydGlAZ29vZ2xlLmNvbT5dDQpTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAxNCwg MjAxMiA3OjI5IFBNDQpUbzogUmF2aW5kcmFuLCBQYXJ0aGFzYXJhdGhpDQpDYzogcnRjd2ViQGll dGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+OyBwdWJsaWMtd2VicnRjQHczLm9yZzxtYWls dG86cHVibGljLXdlYnJ0Y0B3My5vcmc+DQpTdWJqZWN0OiBSZTogU2luZ2xlIG9mZmVyIHdpdGgg bXVsdGlwbGUgYW5zd2VyIGhhbmRsaW5nIGluIEpTRVAgW3dhcyBSRTogW3J0Y3dlYl0gTmV3IEpT RVAgZHJhZnQgcG9zdGVkXQ0KDQpSZWdhcmRpbmcgeW91ciBwcmV2aW91cyBtYWlsLCBhbiBBTlNX RVIgYWZ0ZXIgYW4gQU5TV0VSIHdvdWxkIGVpdGhlciBmYWlsIChpZiB3ZSB3YW50ZWQgdG8gc2lt cGxpZnkpLCBvciByZXBsYWNlIHRoZSBwcmV2aW91cyBBTlNXRVIgKGVzc2VudGlhbGx5IHRoZSBz YW1lIGFzIGlmIHlvdSBoYWQgZG9uZSBzZXRMb2NhbERlc2NyaXB0aW9uKE9GRkVSLCBsb2NhbERl c2NyaXB0aW9uKSBmb2xsb3dlZCBieSBzZXRSZW1vdGVEZXNjcmlwdGlvbihBTlNXRVIsIGFuc3dl cjIpLg0KDQpJbiBubyBjYXNlIHdvdWxkIGl0IG1peCB0aGUgZGVzY3JpcHRpb25zL21lZGlhIGZy b20gYm90aCBhbnN3ZXJzLg0KDQpPdGhlciBjb21tZW50cyBpbmxpbmUgYmVsb3cuDQpPbiBUdWUs IEZlYiAxNCwgMjAxMiBhdCAxOjI0IEFNLCBSYXZpbmRyYW4sIFBhcnRoYXNhcmF0aGkgPHByYXZp bmRyYW5Ac29udXNuZXQuY29tPG1haWx0bzpwcmF2aW5kcmFuQHNvbnVzbmV0LmNvbT4+IHdyb3Rl Og0KSGkgSnVzdGluLA0KDQpBZGRpbmcgdG8gbXkgZWFybGllciBtYWlsLCBJbiBjYXNlIGFuc3dl cjIgU0RQIGlzIHVwZGF0ZWQgaW4gb2ZmZXJlcjEgYnJvd3NlciB3aXRob3V0IG5vdGlmeWluZyBh bnN3ZXJlcjEsIHRoZW4gYW5zd2VyMSB3aWxsIGNvbnRpbnVlIHRvIHRyYW5zbWl0IFJUUCB3aGlj aCBtYXkgbm90IGJlIGRlc2lyZWQgYmVoYXZpb3IuIElNTywgd2UgbmVlZCB0byBkZWZpbmUgdGhp cyBiZWhhdmlvciBjbGVhcmx5IGluIG9mZmVyZXIgc2lkZS4gU29tZSBvZiB0aGUgcG9zc2libGUg c29sdXRpb25zIGFyZQ0KDQoNCjEpICAgICAgb2ZmZXJlcjEgaGFzIHRvIHNlbmQgYXRsZWFzdCBS VENQIEJZRSBwYWNrZXRzIHRvd2FyZHMgYW5zd2VyZXIxIHdoaWxlIGFjY2VwdGluZyB0aGUgYW5z d2VyZXIyIFNEUC4NCg0KMikgICAgICBUaHJvdyBjYWxsYmFjayB0byBjbGVhciBhbnN3ZXIxIFNE UCB0b3dhcmRzIG9mZmVyZXJKUy4NCg0KVGhlIGFwcGxpY2F0aW9uIHdoaWNoIGNhbGxlZCBzZXRS ZW1vdGVEZXNjcmlwdGlvbiB0d2ljZSBzaG91bGQgaGF2ZSB0aGUgYmVzdCBpZGVhIGFib3V0IHdo YXQgaXMgZ29pbmcgb24sIGFuZCB0aGVyZWZvcmUgaXMgcmVzcG9uc2libGUgZm9yIG5vdGlmeWlu ZyBhbnN3ZXJlcjEgdGhhdCBpdHMgYW5zd2VyIGhhcyBiZWVuIGRpc2NhcmRlZCwgaWYgaXQgbWFr ZXMgc2Vuc2UgdG8gZG8gc28uIE5vIGNhbGxiYWNrIHNob3VsZCBiZSBuZWVkZWQgaGVyZS4NCg0K DQpQbGVhc2UgbGV0IG1lIGtub3cgeW91ciBvcGluaW9uIGhlcmUuDQoNClRoYW5rcw0KUGFydGhh DQoNCkZyb206IFJhdmluZHJhbiwgUGFydGhhc2FyYXRoaQ0KU2VudDogVHVlc2RheSwgRmVicnVh cnkgMTQsIDIwMTIgMTI6MDcgQU0NClRvOiAnSnVzdGluIFViZXJ0aSc7IHJ0Y3dlYkBpZXRmLm9y ZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPjsgcHVibGljLXdlYnJ0Y0B3My5vcmc8bWFpbHRvOnB1 YmxpYy13ZWJydGNAdzMub3JnPg0KU3ViamVjdDogU2luZ2xlIG9mZmVyIHdpdGggbXVsdGlwbGUg YW5zd2VyIGhhbmRsaW5nIGluIEpTRVAgW3dhcyBSRTogW3J0Y3dlYl0gTmV3IEpTRVAgZHJhZnQg cG9zdGVkXQ0KDQpIaSBKdXN0aW4sDQoNCkluIHRoZSBkcmFmdCwgaXQgaXMgbm90IHNwZWxsZWQg b3V0IGV4cGxpY2l0bHkgd2hhdCBpcyB0aGUgZXhwZWN0ZWQgYmVoYXZpb3IgaW4gb2ZmZXJlciBi cm93c2VyIGluIGNhc2UgbXVsdGlwbGUgYW5zd2VyIGlzIHJlY2VpdmVkIGZvciBzaW5nbGUgb2Zm ZXIuIE9mZmVyL2Fuc3dlciBleGNoYW5nZSBpbiBvZmZlcmVyIGlzIGFzIGZvbGxvd3M6DQoNCg0K T2ZmZXJlckpTLT5PZmZlcmVyVUE6IHZhciBvZmZlciA9IHBjLmNyZWF0ZU9mZmVyKG51bGwpOw0K T2ZmZXJlckpTLT5PZmZlcmVyVUE6IHBjLnNldExvY2FsRGVzY3JpcHRpb24oU0RQX09GRkVSLCBv ZmZlcik7DQoNCk9mZmVyZXJKUy0+T2ZmZXJlclVBOiAgcGMuc2V0UmVtb3RlRGVzY3JpcHRpb24o U0RQX0FOU1dFUiwgYW5zd2VyMSk7DQoNCk9mZmVyZXJVQS0+QW5zd2VyZXIxVUE6IDxtZWRpYT4N Cg0KT2ZmZXJlckpTLT5PZmZlcmVyVUE6ICBwYy5zZXRSZW1vdGVEZXNjcmlwdGlvbihTRFBfQU5T V0VSLCBhbnN3ZXIyKTsNCg0KT2ZmZXJlclVBLT5BbnN3ZXJlcj9VQTogPG1lZGlhPj8NCg0KTXkg dW5kZXJzdGFuZGluZyBpcyB0aGF0IOKAnGFuc3dlcjLigJ0gd2lsbCB1cGRhdGUg4oCcYW5zd2Vy MeKAnSBpbiBicm93c2VyIGFuZCBzdGFydGluZyBzZW5kaW5nL3JlY2VpdmluZyBtZWRpYSB0b3dh cmRzIGFuc3dlcjIgbWVkaWEgSVAgYW5kIHBvcnQuIENvdWxkIHlvdSBwbGVhc2UgZXhwbGFpbiB0 aGUgZXhwZWN0ZWQgYmVoYXZpb3IgaW4gb2ZmZXJlciBicm93c2VyIHdoZXRoZXIgaXQgdXBkYXRl cyB0aGUgbWVkaWEgc3RyZWFtIGJhc2VkIG9uIHRoZSBsYXN0IGFuc3dlciBvciBtaXhlcyBib3Ro IGFuc3dlcmVyLg0KDQpUaGFua3MNClBhcnRoYQ0KDQpGcm9tOiBydGN3ZWItYm91bmNlc0BpZXRm Lm9yZzxtYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86cnRjd2ViLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKdXN0aW4gVWJlcnRpDQpTZW50OiBUaHVyc2RheSwg RmVicnVhcnkgMDksIDIwMTIgMjoyNyBBTQ0KVG86IHJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRj d2ViQGlldGYub3JnPjsgcHVibGljLXdlYnJ0Y0B3My5vcmc8bWFpbHRvOnB1YmxpYy13ZWJydGNA dzMub3JnPg0KU3ViamVjdDogW3J0Y3dlYl0gTmV3IEpTRVAgZHJhZnQgcG9zdGVkDQoNCk5vdyBh dmFpbGFibGUgYXQgaHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC11YmVydGktcnRjd2ViLWpz ZXAtMDEudHh0DQoNCkluY2x1ZGVzIGNoYW5nZXMgYmFzZWQgb24gaW1wbGVtZW50YXRpb24gZmVl ZGJhY2ssIGFuZCBJIGJlbGlldmUgaXQgYWRkcmVzc2VzIG1vc3Qgb2YgdGhlIGNvbmNlcm5zIHJh aXNlZCBpbiBsYXN0IHdlZWsncyBpbnRlcmltIG1lZXRpbmdzOg0KLSBJbml0aWFsIGRvY3VtZW50 YXRpb24gcHJvdmlkZWQgZm9yIGVhY2ggQVBJIGNhbGwsIGFuZCB3aGF0IHN0YXRlIGNoYW5nZXMg aXQgY2F1c2VzDQotIE1vcmUgZXhhbXBsZXMsIGluY2x1ZGluZyBhIGNvbXBsZXRlIGJhc2ljIHNh bXBsZSBhcHBsaWNhdGlvbg0KLSBTaW1wbGlmaWVkIGFwcHJvYWNoIHRvIHRyaWNrbGUgY2FuZGlk YXRlIGhhbmRsaW5nDQotIFJlc29sdmVkIGNvbmNlcm5zIGFib3V0IGhvdyB0byBzZXBhcmF0ZSBT RFAgYXR0cmlidXRlcyBpbnRvIG1lZGlhIC8gdHJhbnNwb3J0DQotIFByb3ZpZGVkIGVuY2Fwc3Vs YXRpb24gZm9yIFNEUCBibG9icyBhbmQgSUNFIGNhbmRpZGF0ZSBsaW5lcywgaW4gdGhlIGV2ZW50 IHdlIHdhbnQgdG8gY2hhbmdlIGVuY29kaW5ncyBvciBwcm92aWRlIGhlbHBlciBmdW5jdGlvbnMg Zm9yIEpTDQotIFByb3ZpZGVkIG1lY2hhbmlzbSBmb3IgbGltaXRpbmcgY2FuZGlkYXRlcyB0byBU VVJOLW9ubHkNCi0gUmVzb2x2ZWQgc2V2ZXJhbCBpbXBsZW1lbnRhdGlvbiBpc3N1ZXMNCg0KSSBo YXZlIG5vdCB5ZXQgYWRkcmVzc2VkIHRoZSBub24tb3ZlcmxhcHBpbmcgY29kZWMgY29uY2VybiBt ZW50aW9uZWQgaW4gdGhlIGludGVyaW0gbWVldGluZy4gSSB0aGluayB0aGVyZSBhcmUgd2F5cyBv ZiBoYW5kbGluZyB0aGlzIGVpdGhlciBpbiB0aGUgYXBwbGljYXRpb24gb3IgdGhlIGltcGxlbWVu dGF0aW9uLCBidXQgSSB3YW50ZWQgdG8gZ2V0IHRoaXMgLTAxIG91dCBmaXJzdCBmb3IgZmVlZGJh Y2suDQoNCg0KDQo= --_000_387F9047F55E8C42850AD6B3A7A03C6C0E03FC20inbamail01sonus_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmln aHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJp ZiI7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRN TCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAu TXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2lu OjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1z b0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0 eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0 b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9 DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZv cm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkJhbGxv b25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250 LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0K CXttc28tbGlzdC1pZDoxODg5MDI1Mzg4Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1s aXN0LXRlbXBsYXRlLWlkczotMTk5MjE1ODMyOCA2NzY5ODcwNSA2NzY5ODcxMyA2NzY5ODcxNSA2 NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpA bGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXRleHQ6IiUxXCkiOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRv bTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5KdXN0aW4sPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5Tb21lIG9mIHRoZSB1c2VjYXNlcyBjb3VsZCBiZQ0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1 aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6 SWdub3JlIj4xKTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bh bj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRo ZSBzYW1lIHVzZXIgb2YgYSB3ZWJzaXRlIHNpZ25lZC1pbiBpbiB0aGUgbXVsdGlwbGVzIGRldmlj ZXMgYW5kIGFjdHMgYXMgYW5zd2VyZXIsICZuYnNwO3RoZSBzZXNzaW9uIGVzdGFibGlzaG1lbnQg cmVxdWVzdCB0byB0aGUgaWRlbnRpdHkgd2lsbCBhbGVydA0KIGFsbCB0aGUgc2lnbmVkLWluIGRl dmljZXMgYW5kIGl0IGlzIHBvc3NpYmxlIHRoYXQgbXVsdGlwbGUgZGV2aWNlcyBhbnN3ZXIgdG8g dGhlIHNlc3Npb24uIEhlcmUsIHVzZXIgbWF5IG1vdmUgZnJvbSBvbmUgZGV2aWNlIChtb2JpbGUp IHRvIGFub3RoZXIgZGV2aWNlIChkZXNrdG9wKSB3aXRoaW4gdGhlIHNlc3Npb24gYW5kIHdpc2hl cyB0byBjb250aW51ZSB0aGUgc2Vzc2lvbiB3aXRoIHRoZSBsYXN0IGFuc3dlci4gUGxlYXNlIG5v dGUgdGhhdA0KIHdlYnNpdGUgaXMgZmxleGlibGUgdG8gcHJvdmlkZSB0aGlzIHNlcnZpY2UuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0 ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0 TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48c3BhbiBz dHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4yKTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3Nw YW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPlJGQyAzMjYxIFNJUCBVQSBvZmZlci9hbnN3ZXIgaGFuZGxpbmcgdy5yLnQg SU5WSVRFIHdpdGggU0RQIHRvIG11bHRpcGxlIDJ4eCB3aXRoIFNEUCBoYW5kbGluZyBzY2VuYXJp byB1c2luZyBKU0VQPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJh Z3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEi PjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4zKTxzcGFuIHN0eWxlPSJmb250 OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFub3RoZXIgU0lQIHVzZWNhc2UgY291bGQgYmUg bXVsdGlwbGUgMTh4IHJlc3BvbnNlcyB3aXRoIFNEUCBmb3IgSU5WSVRFIHdpdGggU0RQIGFuZCBt dWx0aXBsZSAyeHggcmVzcG9uc2VzIHdpdGhvdXQgU0RQIGJ1dCBvcmRlciB3aXRoaW4gMTh4IGFu ZCAyMDANCiBhcmUgbm90IHNhbWUuIFNheSAyeHggb2YgdGhlIHNlY29uZCAxOHggaXMgcmVjZWl2 ZWQgYXMgdGhlIGZpcnN0IDJ4eC4gSGVyZSwgd2UgbmVlZCB0byBrbm93IGhvdyBzZWNvbmQgMTh4 IGlzIGhhbmRsZWQgYW5kIGFsc28sIHRoZSBzdWJzZXF1ZW50IDJ4eCBpcyBoYW5kbGVkLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+T2YgY291cnNlLCBpdCBpcyBwb3NzaWJsZSB0byBidWlsZCBtb3JlIHVzZWNhc2VzIGFy b3VuZCB0aGlzIGFyZWEuIEFzIHdlIG1hZGUgc2lnbmFsaW5nIG91dHNpZGUgdGhlIHNjb3BlIG9m IFdlYlJUQywgaXQgaXMgdXB0byBKUyBhcHBsaWNhdGlvbiB0byBkZWNpZGUgdGhlDQogb3JkZXIg aW4gd2hpY2ggb2ZmZXIvYW5zd2VyIGhhcHBlbnMuIEnigJltIG5vdCByZWxhdGluZyBvZmZlci9h bnN3ZXIgRlNNIHdpdGggc2Vzc2lvbiBlc3RhYmxpc2htZW50IHN0YXRlIGxpa2UgMTh4LCAyeHgg YnV0IEnigJltIGludGVyZXN0ZWQgaW4ga25vd2luZyBicm93c2VyIG1lZGlhIHBsYW5lIGJlaGF2 aW9yIGluIGRpZmZlcmVudCBzdGF0ZSBvZiBvZmZlci9hbnN3ZXIgaGFuZGxpbmcgYnkgd2hpY2gg SlMgYXBwbGljYXRpb24gYmVoYXZlcyBjb25zaXN0ZW50bHkNCiBpbiBhbGwgYnJvd3NlcnMuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5UaGFua3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UGFydGhhPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQi Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiBKdXN0aW4gVWJlcnRpIFttYWlsdG86anViZXJ0aUBnb29nbGUu Y29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEZlYnJ1YXJ5IDE0LCAyMDEyIDExOjM2 IFBNPGJyPg0KPGI+VG86PC9iPiBSYXZpbmRyYW4sIFBhcnRoYXNhcmF0aGk8YnI+DQo8Yj5DYzo8 L2I+IHJ0Y3dlYkBpZXRmLm9yZzsgcHVibGljLXdlYnJ0Y0B3My5vcmc8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IFNpbmdsZSBvZmZlciB3aXRoIG11bHRpcGxlIGFuc3dlciBoYW5kbGluZyBpbiBK U0VQIFt3YXMgUkU6IFtydGN3ZWJdIE5ldyBKU0VQIGRyYWZ0IHBvc3RlZF08bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QYXJ0aGEsPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPkkgbmVlZCBtb3JlIGluZm9ybWF0aW9uIGFib3V0IHRoZSB1c2UgY2FzZSB0byBwcm92aWRl IGFuIGFjY3VyYXRlIHJlc3BvbnNlLiBBcyBtZW50aW9uZWQgaW4gbXkgZWFybGllciBtYWlsLCBh cmUgYm90aCBhbnN3ZXJzIDJ4eCByZXNwb25zZXM/PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBGZWIgMTQsIDIwMTIgYXQgMTI6MTcgUE0sIFJhdmlu ZHJhbiwgUGFydGhhc2FyYXRoaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnByYXZpbmRyYW5Ac29udXNu ZXQuY29tIj5wcmF2aW5kcmFuQHNvbnVzbmV0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBKdXN0aW4sPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SW4g dGhpcyBtYWlsIHRocmVhZCwgTGV0IHVzIGRlZmluZSB0aGUgYmVoYXZpb3Igb2YgbXVsdGlwbGUg KGF0bGVhc3QgdHdvKSBhbnN3ZXJzIGZvciB0aGUgc2luZ2xlDQogb2ZmZXIgaW4gV2ViUlRDIGJy b3dzZXIuICZuYnNwO05vdywgUGxlYXNlIGxldCBtZSBrbm93IHlvdXIgb3BpbmlvbiBmb3IgbXkg YmVsb3cgbWFpbC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3M8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5QYXJ0aGE8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n OjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+IEp1c3RpbiBVYmVydGkgW21haWx0bzo8YSBocmVmPSJtYWlsdG86anViZXJ0aUBnb29n bGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+anViZXJ0aUBnb29nbGUuY29tPC9hPl0NCjxicj4NCjxi PlNlbnQ6PC9iPiBUdWVzZGF5LCBGZWJydWFyeSAxNCwgMjAxMiA5OjQ3IFBNPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8Yj5U bzo8L2I+IFJhdmluZHJhbiwgUGFydGhhc2FyYXRoaTxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0i bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0Y3dlYkBpZXRmLm9yZzwv YT47IDxhIGhyZWY9Im1haWx0bzpwdWJsaWMtd2VicnRjQHczLm9yZyIgdGFyZ2V0PSJfYmxhbmsi Pg0KcHVibGljLXdlYnJ0Y0B3My5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBTaW5n bGUgb2ZmZXIgd2l0aCBtdWx0aXBsZSBhbnN3ZXIgaGFuZGxpbmcgaW4gSlNFUCBbd2FzIFJFOiBb cnRjd2ViXSBOZXcgSlNFUCBkcmFmdCBwb3N0ZWRdPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBUdWUsIEZlYiAxNCwgMjAx MiBhdCA2OjM5IEFNLCBSYXZpbmRyYW4sIFBhcnRoYXNhcmF0aGkgJmx0OzxhIGhyZWY9Im1haWx0 bzpwcmF2aW5kcmFuQHNvbnVzbmV0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnByYXZpbmRyYW5Ac29u dXNuZXQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkhpIEp1c3Rpbiw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JdCB3aWxsIGJlIGdvb2QgdG8gbWVudGlv biBpbiB0aGUgSlNFUCBkcmFmdCAmbmJzcDt0aGF0IG11bHRpcGxlIGFuc3dlcnMgZm9yIHNpbmds ZSBvZmZlciB3aWxsIG5vdCBsZWFkDQogdG8gUlRQIE1peGluZyBhbmQgV2ViUlRDIGNsaWVudCBh Y3RzIGFzIFJUUCBFbmRwb2ludC4gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RmFpbGluZyB0aGUgc2Vjb25kIEFu c3dlciB3aWxsIGJlIGxpbWl0aW5nIHRoZSBwcm92aXNpb24gaW4gUkZDIDMyNjQgb2ZmZXIvYW5z d2VyIGl0c2VsZiBhcyBSRkMgMzI2NA0KIHN1cHBvcnRzIHNpbmdsZSBvZmZlciB3aXRoIG11bHRp cGxlIGFuc3dlci4gQWxzbywgaXQgaXMgYmV0dGVyIHRvIGRlZmluZSB0aGUgYmVoYXZpb3IgaW4g QVBJIHJhdGhlciB0aGFuIHB1dHRpbmcgdGhpcyBzY2VuYXJpbyBpbiB0aGUgYnJvd3NlciBpbXBs ZW1lbnRhdGlvbiBzcGVjaWZpYy4gSW4gc2ltcGxlIHNjZW5hcmlvcyAobGlrZSBhbGVydGluZyB3 aXRoIG9uZSBhbnN3ZXIsIGNvbm5lY3Qgd2l0aCBzZWNvbmQgYW5zd2VyKSwgcmVwbGFjaW5nDQog dGhlIHByZXZpb3VzIEFOU1dFUiB3aWxsIGJlIGV4cGVjdGVkIGJlaGF2aW9yLiBUaGlzIG1heSBu b3QgYmUgZGVzaXJlZCBiZWhhdmlvciBpbiBjYXNlIHR3byBjb25uZWN0IHJlc3BvbnNlcyBmcm9t IGRpZmZlcmVudCBXZWJSVEMgY2xpZW50cyByZWNlaXZlZCB3aXRoIGRpZmZlcmVudCBhbnN3ZXJz ICZuYnNwO2J1dCB0aGVyZSBpcyBubyBvdGhlciBhbHRlcm5hdGl2ZSBzb2x1dGlvbiBwb3NzaWJs ZSB3aXRob3V0IG1peGluZy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkRvIHlvdSBuZWVkIHRvIHN1cHBvcnQg MiBmaW5hbCBhbnN3ZXJzLCBvciB3b3VsZCB0aGUgcHJvdmlzaW9uYWwgYW5zd2VyIHN1cHBvcnQg cHJvdmlkZWQgdmlhIFNEUF9QUkFOU1dFUiB3b3JrIGZvciB5b3U/PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5JTU8sIGl0IGlzIGJldHRlciB0byBkZWZpbmUgaXQgZXhwbGljaXRseSBpbiBKU0VQIHRo YXQg4oCcbGF0ZXN0IEFOU1dFUiB0byB0aGUgb2ZmZXIgd2lsbCByZXBsYWNlIHRoZQ0KIGV4aXN0 aW5nIGFuc3dlciBpcyB0aGUgZXhwZWN0ZWQgYmVoYXZpb3Ig4oCdLiBBbHNvLCBQbGVhc2UgbWVu dGlvbmVkIHRoYXQgSlMgYXBwbGljYXRpb24gaXMgcmVzcG9uc2libGUgZm9yIGRpc2NhcmRpbmcg KHRlcm1pbmF0aW5nKSBwcmV2aW91cyBBTlNXRVIgbm90aWZpY2F0aW9uLiAmbmJzcDsmbmJzcDtQ bGVhc2UgbGV0IG1lIHlvdXIgb3BpbmlvbiBvbiB0aGlzIGNsb3N1cmUuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ VGhhbmtzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UGFydGhhPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBp biAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBKdXN0aW4gVWJlcnRpIFttYWls dG86PGEgaHJlZj0ibWFpbHRvOmp1YmVydGlAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmp1 YmVydGlAZ29vZ2xlLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgRmVicnVh cnkgMTQsIDIwMTIgNzoyOSBQTTxicj4NCjxiPlRvOjwvYj4gUmF2aW5kcmFuLCBQYXJ0aGFzYXJh dGhpPGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+cnRjd2ViQGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOnB1YmxpYy13 ZWJydGNAdzMub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpwdWJsaWMtd2VicnRjQHczLm9yZzwvYT48 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFNpbmdsZSBvZmZlciB3aXRoIG11bHRpcGxlIGFuc3dl ciBoYW5kbGluZyBpbiBKU0VQIFt3YXMgUkU6IFtydGN3ZWJdIE5ldyBKU0VQIGRyYWZ0IHBvc3Rl ZF08L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5SZWdhcmRpbmcgeW91ciBwcmV2aW91cyBtYWlsLCBhbiBBTlNXRVIgYWZ0ZXIg YW4gQU5TV0VSIHdvdWxkIGVpdGhlciBmYWlsIChpZiB3ZSB3YW50ZWQgdG8gc2ltcGxpZnkpLCBv ciByZXBsYWNlIHRoZSBwcmV2aW91cyBBTlNXRVIgKGVzc2VudGlhbGx5IHRoZSBzYW1lIGFzIGlm IHlvdSBoYWQgZG9uZSBzZXRMb2NhbERlc2NyaXB0aW9uKE9GRkVSLA0KIGxvY2FsRGVzY3JpcHRp b24pIGZvbGxvd2VkIGJ5IHNldFJlbW90ZURlc2NyaXB0aW9uKEFOU1dFUiwgYW5zd2VyMikuPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SW4gbm8gY2Fz ZSB3b3VsZCBpdCBtaXggdGhlIGRlc2NyaXB0aW9ucy9tZWRpYSBmcm9tIGJvdGggYW5zd2Vycy48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPk90aGVy IGNvbW1lbnRzIGlubGluZSBiZWxvdy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPk9uIFR1ZSwgRmViIDE0LCAyMDEyIGF0IDE6MjQgQU0sIFJhdmluZHJhbiwg UGFydGhhc2FyYXRoaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnByYXZpbmRyYW5Ac29udXNuZXQuY29t IiB0YXJnZXQ9Il9ibGFuayI+cHJhdmluZHJhbkBzb251c25ldC5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgSnVzdGluLDwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkFkZGluZyB0byBteSBlYXJsaWVyIG1haWwsIEluIGNhc2UgYW5zd2VyMiBTRFAgaXMg dXBkYXRlZCBpbiBvZmZlcmVyMSBicm93c2VyIHdpdGhvdXQgbm90aWZ5aW5nIGFuc3dlcmVyMSwN CiB0aGVuIGFuc3dlcjEgd2lsbCBjb250aW51ZSB0byB0cmFuc21pdCBSVFAgd2hpY2ggbWF5IG5v dCBiZSBkZXNpcmVkIGJlaGF2aW9yLiBJTU8sIHdlIG5lZWQgdG8gZGVmaW5lIHRoaXMgYmVoYXZp b3IgY2xlYXJseSBpbiBvZmZlcmVyIHNpZGUuIFNvbWUgb2YgdGhlIHBvc3NpYmxlIHNvbHV0aW9u cyBhcmU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6 MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cD48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+MSk8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsN Cjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+b2ZmZXJl cjEgaGFzIHRvIHNlbmQgYXRsZWFzdCBSVENQIEJZRSBwYWNrZXRzIHRvd2FyZHMgYW5zd2VyZXIx IHdoaWxlIGFjY2VwdGluZyB0aGUgYW5zd2VyZXIyIFNEUC4mbmJzcDsNCjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4y KTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5UaHJvdyBjYWxsYmFjayB0byBjbGVhciBhbnN3ZXIxIFNEUCB0 b3dhcmRzIG9mZmVyZXJKUy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSBhcHBs aWNhdGlvbiB3aGljaCBjYWxsZWQgc2V0UmVtb3RlRGVzY3JpcHRpb24gdHdpY2Ugc2hvdWxkIGhh dmUgdGhlIGJlc3QgaWRlYSBhYm91dCB3aGF0IGlzIGdvaW5nIG9uLCBhbmQgdGhlcmVmb3JlIGlz IHJlc3BvbnNpYmxlIGZvciBub3RpZnlpbmcgYW5zd2VyZXIxIHRoYXQgaXRzIGFuc3dlciBoYXMN CiBiZWVuIGRpc2NhcmRlZCwgaWYgaXQgbWFrZXMgc2Vuc2UgdG8gZG8gc28uIE5vIGNhbGxiYWNr IHNob3VsZCBiZSBuZWVkZWQgaGVyZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRp dj4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UGxlYXNlIGxldCBtZSBrbm93 IHlvdXIgb3BpbmlvbiBoZXJlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rczwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPlBhcnRoYQ0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPiBSYXZpbmRyYW4sIFBhcnRoYXNhcmF0aGkNCjxicj4NCjxiPlNlbnQ6 PC9iPiBUdWVzZGF5LCBGZWJydWFyeSAxNCwgMjAxMiAxMjowNyBBTTxicj4NCjxiPlRvOjwvYj4g J0p1c3RpbiBVYmVydGknOyA8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+cnRjd2ViQGlldGYub3JnPC9hPjsNCjxhIGhyZWY9Im1haWx0bzpwdWJsaWMtd2Vi cnRjQHczLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnB1YmxpYy13ZWJydGNAdzMub3JnPC9hPjxicj4N CjxiPlN1YmplY3Q6PC9iPiBTaW5nbGUgb2ZmZXIgd2l0aCBtdWx0aXBsZSBhbnN3ZXIgaGFuZGxp bmcgaW4gSlNFUCBbd2FzIFJFOiBbcnRjd2ViXSBOZXcgSlNFUCBkcmFmdCBwb3N0ZWRdPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIEp1c3Rpbiw8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5JbiB0aGUgZHJhZnQsIGl0IGlzIG5vdCBzcGVsbGVkIG91dCBleHBsaWNp dGx5IHdoYXQgaXMgdGhlIGV4cGVjdGVkIGJlaGF2aW9yIGluIG9mZmVyZXIgYnJvd3NlciBpbg0K IGNhc2UgbXVsdGlwbGUgYW5zd2VyIGlzIHJlY2VpdmVkIGZvciBzaW5nbGUgb2ZmZXIuIE9mZmVy L2Fuc3dlciBleGNoYW5nZSBpbiBvZmZlcmVyIGlzIGFzIGZvbGxvd3M6PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHByZT5PZmZl cmVySlMtJmd0O09mZmVyZXJVQTogdmFyIG9mZmVyID0gcGMuY3JlYXRlT2ZmZXIobnVsbCk7PG86 cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPk9mZmVyZXJK Uy0mZ3Q7T2ZmZXJlclVBOiBwYy5zZXRMb2NhbERlc2NyaXB0aW9uKFNEUF9PRkZFUiwgb2ZmZXIp Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwcmU+T2ZmZXJlckpTLSZndDtPZmZlcmVyVUE6Jm5i c3A7IHBjLnNldFJlbW90ZURlc2NyaXB0aW9uKFNEUF9BTlNXRVIsIGFuc3dlcjEpOzxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPk9mZmVyZXJVQS0mZ3Q7QW5zd2VyZXIxVUE6ICZsdDttZWRpYSZndDs8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5PZmZlcmVySlMtJmd0O09mZmVyZXJVQTombmJzcDsgcGMu c2V0UmVtb3RlRGVzY3JpcHRpb24oU0RQX0FOU1dFUiwgYW5zd2VyMik7PG86cD48L286cD48L3By ZT4NCjxwcmU+T2ZmZXJlclVBLSZndDtBbnN3ZXJlcj9VQTogJmx0O21lZGlhJmd0Oz88bzpwPjwv bzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IOKAnGFu c3dlcjLigJ0gd2lsbCB1cGRhdGUg4oCcYW5zd2VyMeKAnSBpbiBicm93c2VyIGFuZCBzdGFydGlu ZyBzZW5kaW5nL3JlY2VpdmluZw0KIG1lZGlhIHRvd2FyZHMgYW5zd2VyMiBtZWRpYSBJUCBhbmQg cG9ydC4gQ291bGQgeW91IHBsZWFzZSBleHBsYWluIHRoZSBleHBlY3RlZCBiZWhhdmlvciBpbiBv ZmZlcmVyIGJyb3dzZXIgd2hldGhlciBpdCB1cGRhdGVzIHRoZSBtZWRpYSBzdHJlYW0gYmFzZWQg b24gdGhlIGxhc3QgYW5zd2VyIG9yIG1peGVzIGJvdGggYW5zd2VyZXIuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ VGhhbmtzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UGFydGhhPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBp biAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KPGEgaHJlZj0ibWFpbHRvOnJ0 Y3dlYi1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cnRjd2ViLWJvdW5jZXNAaWV0 Zi5vcmc8L2E+IFs8YSBocmVmPSJtYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5tYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVo YWxmIE9mIDwvYj5KdXN0aW4gVWJlcnRpPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBGZWJy dWFyeSAwOSwgMjAxMiAyOjI3IEFNPGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86cnRj d2ViQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cnRjd2ViQGlldGYub3JnPC9hPjsgPGEgaHJl Zj0ibWFpbHRvOnB1YmxpYy13ZWJydGNAdzMub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpwdWJsaWMt d2VicnRjQHczLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW3J0Y3dlYl0gTmV3IEpTRVAg ZHJhZnQgcG9zdGVkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPk5vdyBhdmFpbGFibGUgYXQNCjxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQv ZHJhZnQtdWJlcnRpLXJ0Y3dlYi1qc2VwLTAxLnR4dCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDov L3d3dy5pZXRmLm9yZy9pZC9kcmFmdC11YmVydGktcnRjd2ViLWpzZXAtMDEudHh0PC9hPjxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkluY2x1ZGVzIGNo YW5nZXMgYmFzZWQgb24gaW1wbGVtZW50YXRpb24gZmVlZGJhY2ssIGFuZCBJIGJlbGlldmUgaXQg YWRkcmVzc2VzIG1vc3Qgb2YgdGhlIGNvbmNlcm5zIHJhaXNlZCBpbiBsYXN0IHdlZWsncyBpbnRl cmltIG1lZXRpbmdzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4tIEluaXRpYWwgZG9jdW1lbnRhdGlvbiBwcm92aWRlZCBmb3IgZWFjaCBBUEkg Y2FsbCwgYW5kIHdoYXQgc3RhdGUgY2hhbmdlcyBpdCBjYXVzZXM8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LSBNb3JlIGV4YW1wbGVzLCBpbmNs dWRpbmcgYSBjb21wbGV0ZSBiYXNpYyBzYW1wbGUgYXBwbGljYXRpb248bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LSBTaW1wbGlmaWVkIGFwcHJv YWNoIHRvIHRyaWNrbGUgY2FuZGlkYXRlIGhhbmRsaW5nPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0gUmVzb2x2ZWQgY29uY2VybnMgYWJvdXQg aG93IHRvIHNlcGFyYXRlIFNEUCBhdHRyaWJ1dGVzIGludG8gbWVkaWEgLyB0cmFuc3BvcnQ8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LSBQcm92 aWRlZCBlbmNhcHN1bGF0aW9uIGZvciBTRFAgYmxvYnMgYW5kIElDRSBjYW5kaWRhdGUgbGluZXMs IGluIHRoZSBldmVudCB3ZSB3YW50IHRvIGNoYW5nZSBlbmNvZGluZ3Mgb3IgcHJvdmlkZSBoZWxw ZXIgZnVuY3Rpb25zIGZvciBKUzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4tIFByb3ZpZGVkIG1lY2hhbmlzbSBmb3IgbGltaXRpbmcgY2FuZGlk YXRlcyB0byBUVVJOLW9ubHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+LSBSZXNvbHZlZCBzZXZlcmFsIGltcGxlbWVudGF0aW9uIGlzc3Vlczxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ SSBoYXZlIG5vdCB5ZXQgYWRkcmVzc2VkIHRoZSBub24tb3ZlcmxhcHBpbmcgY29kZWMgY29uY2Vy biBtZW50aW9uZWQgaW4gdGhlIGludGVyaW0gbWVldGluZy4gSSB0aGluayB0aGVyZSBhcmUgd2F5 cyBvZiBoYW5kbGluZyB0aGlzIGVpdGhlciBpbiB0aGUgYXBwbGljYXRpb24gb3IgdGhlIGltcGxl bWVudGF0aW9uLA0KIGJ1dCBJIHdhbnRlZCB0byBnZXQgdGhpcyAtMDEgb3V0IGZpcnN0IGZvciBm ZWVkYmFjay48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_387F9047F55E8C42850AD6B3A7A03C6C0E03FC20inbamail01sonus_-- From fluffy@iii.ca Tue Feb 14 13:06: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 2EC5E21E8112 for ; Tue, 14 Feb 2012 13:06:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.006 X-Spam-Level: X-Spam-Status: No, score=-2.006 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_00=-2.599, J_CHICKENPOX_111=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_92=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 Y8dk39emfYnT for ; Tue, 14 Feb 2012 13:06:10 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 5FBDD21E8036 for ; Tue, 14 Feb 2012 13:06:10 -0800 (PST) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id DA4F922E256; Tue, 14 Feb 2012 16:06:03 -0500 (EST) From: Cullen Jennings Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Tue, 14 Feb 2012 14:06:01 -0700 Message-Id: <03535710-04A3-43C2-8D96-D93CC1797366@iii.ca> To: rtcweb@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [rtcweb] Draft minutes for 82.5 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, 14 Feb 2012 21:06:12 -0000 Here is a draft of the minutes for the last interim meeting. Please let = us know if any corrections are needed by the end of Feb 22. Many thanks = to Mary, Alan, and Ashish who took the minutes.=20 Thanks,=20 Cullen, Magnus, & Ted Minutes=20 RTCWEB Interim Meeting January 31st & February 1st, 2012 Chairs: Ted Hardie, Cullen Jennings, Magnus Westerlund Minutes: Mary Barnes, Alan Johnston, Ashish V. Thapliyal Agenda: = http://www.ietf.org/proceedings/interim/2012/01/31/rtcweb/agenda/rtcweb.tx= t Jabber log: http://www.ietf.org/jabber/logs/rtcweb/2012-01-31.html http://www.ietf.org/jabber/logs/rtcweb/2012-02-01.html Presentations: = http://www.ietf.org/proceedings/interim/2012/01/31/rtcweb/proceedings.html= No audio recording is available. Action items: Chairs to confirm consensus on the use of SCTP as a data transport. Chairs to confirm consensus that layering of SCTP would be = SCTP/DTLS/UDP. Chairs to confirm consensus on JSEP / ROAP question Justin Uberti to provide -01 draft of JSEP as an individual submission. Hadriel Kaplan and Eric Rescorla to update architecture draft with text = on use of ICE extensions/flags to indicate consent. Working group to gather SDES deployment data by IETF 83 to drive = discussion on permitted modes for media security (browser-to-browser = secure, javascript visible, unprotected). Working group to review IdP proposals and be prepared to decide at IETF = 82 on basic model. Other conclusions: No objections to Harald taking MSID to MMUSIC. The group encouraged progress on bundle in MMUSIC. Attendees: Justin Uberti, Leon Portman, Jonathan Lennox, Wonsuk Lee, Soo-Hyun Choi, Anant Narayanan, Aleksandr Avseyev, Gonzalo Camarillo, Dan Burnett, Rohit Puri, Stephan Wenger, Mauro Cabutto, Robert Sparks, Timothy Terriberry, Bernard Aboba, Mary Barnes, Venkatesh Venkataramanan, Jim Barnett, Andrew Hutton, Xavier Marjou, Randall Stewart, Henry Lum, Milan Young, Yair Wiener, Aron Rosenberg, Dan Druta, Christer Holmberg, Spencer Dawkins, Oscar Ohlsson, Neil Stratford, Marc Petit-Huguenin, Eric Rescorla, Markus Isomaki, Ashish Thapliya, Mathieu Hofman, Stefan Hakansson, Jonathan Lennox, Matthew Kaufman, Mahalingam Mani, Cullen Jennings, Magnus Westerlund, Harald Alvestrand, Michael Thornburgh, Alan Johnston, Martin Thomson, Randell Jesup, Maire D. Reavy, Cary Fitzgerald, Li Zhengdong, Jonathan Rosenberg, Ted Hardie, Mathieu Hofman, Ashish Thapliyal, Adam Bergkvist, Lars Eggert, Suhas Nandakumar, Hadriel Kaplan, Robert Wolff, Manjesh Malavalli, Alexey Aylarov, Dan Wing, Lazar Bivolarski Discussion Summaries: Day 1 JSEP Review -Justin Uberti Goals: Allow easy translation to common signaling protocols and architectures Support early transport negotiation Allow local description to be changed by app Change session parameters at any time Allow direct manipulation of session state Give app as much flexibility as possible, now and in the future=20 Non-goals: Super-simple API Replace SDP Offer generation in JS (at least not right now) JSEP Key concepts: Signaling and transport are separated Signaling state moved into application code Media controlled via local and remote session descriptions (SDP blobs) The "how" of the signaling is left to the application; only the results = of the signaling matter=20 Different signaling protocols have different features and mechanisms: Candidate handling Glare handling/Tie breaking Adding or removing sources or sessions RTP Session updates=20 Basically, hard to have a generic signaling mechanism that can map = faithfully to all signaling state machines, but that severely limits = functionality, i.e., LCD.=20 Needs of media layer: Local format description What I want/am going to do Remote format description What the other side wants/is going to do Local/remote transport info Where is media going to go, and how Discussion of ICE state machine at remote side, both for rehydration and = interface changes. (Rehydration is the recovery/restart of a session = after a reload) Summarize: need to figure how not to have to redo ICE. Discussion of adding and removing streams, leading to discussion of = offer/answer model and where the offer state machine lives. Discussion of a glare-less add, which is based on a delta. Discussion = of whether this a capabilities exchange or offer answer; conclusion that = it doesn't preclude RFC 3264 Offer/Answer, but it also allows other = handling. Things you can do: Send candidates as they are gathered Add/remove sources simultaneously Change session parameters at any time (with or without an O/A exchange) Control local session description that is generated and sent Rehydrate a session from stored state=20 New APIS: creating SDP createOffer (hints): Creates a session description based on the = current local media state; |hints| allows for some customization. Does = not reserve resources, or change state. createAnswer(offer, hints): Like createOffer, but uses |offer| as = input to create a compatible session description. Long discussion of where complexity should be. New APIs: Applying SDP setLocalDescription(type, desc) Applies the local description, e.g. recv codecs, encryption keys. = Changes state. setRemoteDescription(type, desc) Applies the remote description, e.g. send codecs, decryption keys.=20 Throws exception on invalid state or params=20 Discussion of complexity of these and the granularity of error codes.: New APIs: ICE IceCallback(media, transportInfo) Callback function that receives transport information that needs to be = signaled processIceMessage(media, transportInfo) Invoked to handle received transport information=20 =20 Session Descriptions Standard SDP Transport Info a=3Dice-candidate lines a=3Dice-ufrag, password lines a=3Dfingerprint (for DTLS) a=3Dgroup (for BUNDLE) =20 Discussion of complexity. JSEP does require more code (~60 lines for a basic example, w/o glare = handling), but can be encapsulated within a JS library, which might also = perform protocol translation too (e.g. convert to SIP, XMPP, or ROAP). It was noted that it will need more specification of the API, in = addition to more code. Noted that some developers bundle a library with = application, so don't get updates. A more symmetric API may be easier = to use. Argued that it is possible to build ROAP on JSEP. JSEP vs ROAP (first presentation view) Key differences: Signaling mechanism lives in app/JS Early transport negotiation supported App has control over local description App can change session parameters at any time, without O/A if desired App can restore session from cached state More JS code, but under app control=20 Glare conditions become a non-issue for many apps Features can be added without new browser APIs (e.g. one-way video, = hold, res change) Calls can persist across application upgrades=20 13:00-14:18 ROAP (Cullen) -Updates since last presentation -Contrast between JSEP and ROAP=20 ROAP Design Rationale=20 Be the simplest protocol possible that can do RFC 3264 Offer/Answer with = SDP Concerns about an SDP-based interface: 1. Forces browser to be conscious of SDP offer/answer state 2. Speed of call setup 3. State resurrection on page reload=20 Managing codec resources - =46rom RFC 3264: (review of allocation, sending media, and freeing) Modifying the SDP offer/answer pair state.=20 How the media engine ends up needing outstanding offer state concern is = that this is so deeply embedded that you can separate out.=20 What is SDP state? Resources allocated for Old and New SDP When to free Old resources, when to free New Examples of Offer/answer=20 Discussion of "sdp state" vs. "browser state"=20 Review of how Peerconnection might tell a JS application of the SDP changes needed for HOLD. Digression into UI. Review of diagram on quick call setup, and causes of delay. Extensive discussion of what optimizations are possible and the security = consequences. The need to run ICE to completion, rather than have the = server generate secrets marks the limits here. Proposal to add Candidates message to ROAP=20 Hard to separate the transport information out of SDP but there is one = thing that looks like it could be done to allow "trickle ICE" Make a new ROAP message called CANDIDATE with new candidates. This = message can be sent at any time and each element in the array augments = the candidates in the previous SDP offer/answer CANDIDATE message structure: array of sets of candidate lines. The n'th = element in the array is added to the candidates for the n'th "m=3D" line Believe (hope) this will not break ICE because ICE already allows new = candidates in form of peer reflexive at any point in time Need cost/benefit analysis of performance improvement versus potential = problems Thoughts? Experiment with this - try out? Discussion of compatibility issues and advantages; worthwhile to examine = syntax. Discussion of slide describing the bits of SDP involved in transport. Discussion of resurrection/rehydration on page reload. Should this redo = ICE? =20 Proposal: JS to control update timing=20 Current ROAP API calls a callback with new SDP anytime something = changes JS expected to send SDP immediately Instead it could call a callback indicating "conditions changed; new = SDP required"=F9.The JS Application would then be able to ask for the = new SDP and send it Not clear where this flexibility helps but it would not be hard to = add and would match JSEP in this regard Discussion of the offer/answer limitations with multiple offers. Table = of design choices: - Use SDP O/A Pros: finished and deployed. Cons: Ugly. Timeline: 4 = months. - Separate transport out of SDP. Pros: architectural purity. Cons: hard = to figure out what might break. Timeline: 12 months - Replace SDP. Pros: SDP is hideous Cons: very hard to deploy. = Timeline: many years. This carried into general design resolution, for which please see the = jabber logs. Consensus questions? =20 1--Don't care whether ROAP or JSEP is the input document for further work in this area 2---Prefer ROAP be the input document for further work 3--Prefer JSEP be the input document for further work 4--Prefer to merge the docs, limiting JSEP to RFC 3264 offer/answer = semantics. The results were:=20 1=3D9 in room, none in jabber 2=3D11 in room, 2 in jabber 3=3D25 in room, 3 in jabber 4=3D8 in room, none in jabber. Consensus to be confirmed on the list. 15:45-16:20 ish MSID (Harald)=20 Possible solutions Basic issue relates to mapping streams and tracks. Possible responses: Ignore problem - Works badly with multiple streams Use existing identifiers - SSRC: Doesn't exist until PeerConnection connected;it fits with = track, but not with stream - CNAME - Has other semantics (synchronization, source) =20 - RTP session / SDP m-line: Unique media type breaks MediaStream = concept Add a new identifier: Nonstandard, API only or Standard, carried in = SDP blobs Extensive discussion; eventual belief that this is a new semantic, which = might be useful outside of RTCWEB. No objection to it going to MMUSIC = for further work. 16:30-17:30 Data channel (1) (Randall)=20 Uses Side channels during a 'call' (mute status, etc) Chat File transfer Application synchronization Games Shared whiteboard Co-browsing Shared document editing (with audio and/or video) Many uses we haven't thought of yet Data Channel Requirements Multiple data channels Reliable and unreliable Datagram and Stream (if reliable) paradigms MUST be congestion-controlled MUST be secure (*) Quality open-source userland implementation needed for deployment See draft for other implementation requirements Discussion of whether these requirements can be derived from use cases. = Discussion of how much is gained by having an unreliable data channel Reviewed the pros and cons of Pseudo-TCP over UDP, DCCP, SCTP-DTLS, = DTLS-SCTP Open issues:=20 SCTP: Michael Thornburg's issues - Blocking of other channels if one isn't = serviced Draft for SCTP-DTLS needed if chosen Interleaving of large datagrams DCCP: Is a userland implementation available? Quality? General:=20 Inter-stream priority (nice-to-have) Congestion control interactions with app and media streams PMTU sensing Long discussion of congestion control methods; SCTP's plugabble = congestion control emerged as a major advantage. =20 Consensus call: Do you want something other than SCTP for data transport protocol? (3) Do you want SCTP? (19) Question: Do you have enough data to decide on SCTP layering? Review of the differences. SCTP-DTLS-UDP (18) DTLS-SCTP-UDP (0) Consensus calls confirming SCTP and layering to go to the list. =20 Day 2 February 1, 2012 Security Topic - Eric Rescorla (Ekr) Security arch document: draft-ietf-rtcweb-security-arch-00 Issue: Mixed Content Proposal: Remove RTCWEB permissions for origins with mixed content Discussion about MUST vs SHOULD What if page becomes mixed content during a session? Ekr will write text with proposal in next version of draft. Issue: Content Freshness/Keepalives Proposal: MUST use STUN binding requests (not indications) every 30s Discussion about ICE extensions/flags to indicate consent Discussion that this only prevents browsers from being used in attacks - = others could still do a flooding attack Discussion that RTCP is not useful for this. Ekr will write some text with help from Hadriel on this. Issue: Media Security Requirements DTLS-SRTP or SDES or RTP Try to make a decision in Paris based on SDES deployment data Two security models proposed: Browser-to-browser secure, Javascript = visible Example given Google Chat "off the record" button Discussion about value if users don't check fingerprint or use an = Identity service Discussion about forking of media Discussion of tradeoff between complexity vs benefit More on this during Randell Jessup's presentation (W3C WEBRTC) Discussion that this is useful if coupled with identity service Discussion that identity could be a service and not the website Generic Identity Service - Eric Rescorla (Ekr) draft-rescorla-rtcweb-generic-idp-00 Goals presented Discussion about how this is bad for services that want to be able to record media Discussion that a web page could play recorded media instead of real = media Discussion that it isn't that you don't trust your own site, but you = don't trust the other guy's site - federation case Overview presented with topology diagram Types of Identity Providers (IdP) presented Discussion of IdP that relates to telephone numbers - not clear which = case this is - perhaps a third category is needed Discussion about number portability, Viper, iMessage use of phone = numbers User Relationships with IdPs Web-based IdP Systems Facebook Connect example (slide 42 (not slide 23) shows example screen) BrowserID example Discussion about sharing across mobile and desktop devices Discussion about delegated vs federated identity Window Communication - PostMessage Discussion about how this affects mixed media case Iframes What are we trying to accomplish? Discussion about permissions being per user and not per browser - tied = to a session ROAP Example with BrowserID Discussion about having multiple IdPs used - it is possible JSEP Example and Facebook Connect What needs to be defined Discussion about what this means - how media is rendered What needs to be signed Discussion about signing ICE candidates - perhaps not necessary Discussion about only verifying part: fingerprint but not ICE candidates - possible, but needs multiple signature blocks Security Properties of ICE Candidates Discussion that it is an advantage not to protect the ICE candidates Discussion that the TURN server could be provided by browser and trusted by user - configured by user similar to HTTP proxy, etc. Discussion about how SBCs today insert themselves as a TURN ICE = candidate Discussion about whether every JSEP message will need to be signed - avoid this by only signing fingerprint Discussion that could avoid having to go back to IdP for every message Discussion about protecting against traffic analysis by protecting ICE candidates Discussion about the difficulty of allowing different information to be = signed, when the net result is binary: this is Alice or this isn't = Alice. Discussion about having different TURN servers in different directions Skipped slides of Security of Media Parameters Generic Structure for Identity Assertions How does PeerConnection know IdP domain? Discussion about multiple choices of IdP and trust anchors and if an IdP = is less trustworthy than another - choice of authoritative vs 3rd party Discussion about how to avoid state sponsored IdPs, e.g. Iranian = government - how to avoid popups and trying to explain 3rd party = assertions Discussion about only using authoritative assertions - ignoring third = party assertions Discussion about multiple active sessions - need to be able to = interrogate using browser chrome Incoming Message Checks (IdP Proxy) Discussion about using // - don't have to use Integrated IdP Support Chairs: not ready to make decisions today. Everyone should read, think, = and be ready make decisions in Paris Support for SDES in RTCWEB - Oscar Olson Decisions to be Made Question: have we made the decision to disallow plain RTP decision? = Chairs: No Question: we need to decide RTP before SDES Why even consider SDES? Discussion if interop is important, then RTP needs to be discussed Why is interworking simplified? Discussion that 100% of 4G handsets also contain browsers, so this might = be the upgrade path Discussion we need to know what X is (% of existing that support/use = SDES) Discussion that devices facing the public Internet is the key question - there is more SRTP used than inside the firewall. Discussion about DTLS-SRTP encryption/decryption - could use EKT to = avoid this Discussion that avoiding clipping is important, as SDES avoids extra = round trips Chairs: Encourage Dan Wing to continue work on use of EKT to avoid encrypt/decrypt in gateway. Security Implications of SDES Discussion about undetectable, but not plausible Discussion about MitM that users must trust man in the middle or check fingerprints/use IdP - can't put lock icon on SDES Discussion that SDES does not have protection against passive attacks and forward secrecy Discussion that conclusion that SDES can be used securely is false. Ran out of time and ended on slide 6. Chairs: Question of legacy interop - how do we detect when legacy interop is happening - please discuss on the list. Chairs: Want activity before Paris, don't stop work. From fluffy@iii.ca Wed Feb 15 00:01: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 3E6FB21E8046 for ; Wed, 15 Feb 2012 00:01:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.871 X-Spam-Level: X-Spam-Status: No, score=-2.871 tagged_above=-999 required=5 tests=[AWL=-0.272, 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 qyLO6tlh-Sa9 for ; Wed, 15 Feb 2012 00:01:14 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 10CF921E800C for ; Wed, 15 Feb 2012 00:01:13 -0800 (PST) Received: from sjc-vpn5-2025.cisco.com (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 EB5D022E256; Wed, 15 Feb 2012 03:01:06 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Cullen Jennings In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E03FC20@inba-mail01.sonusnet.com> Date: Wed, 15 Feb 2012 00:01:05 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <9ED4A9AC-37C7-4E6D-B6C6-4D3C9537B356@iii.ca> References: <387F9047F55E8C42850AD6B3A7A03C6C0E03F8A4@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E03FAB5@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E03FB7C@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E03FC20@inba-mail01.sonusnet.com> To: "Ravindran, Parthasarathi" X-Mailer: Apple Mail (2.1257) Cc: "public-webrtc@w3.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Single offer with multiple answer handling in JSEP [was RE: New JSEP draft posted] 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, 15 Feb 2012 08:01:15 -0000 I'm a bit lost on use case in SIP context - assuming that the UAC did = not fork but that a proxy or B2BUA did the forking, it seems like the = UAC should never receive more than one final response.=20 In the case of moving from desktop to mobile, it seems like that is = updating the stream and would use a call flow more like update examples = in the draft instead of trying to reuse some old answer.=20 On Feb 14, 2012, at 11:24 , Ravindran, Parthasarathi wrote: > Justin, > =20 > Some of the usecases could be > 1) The same user of a website signed-in in the multiples devices = and acts as answerer, the session establishment request to the identity = will alert all the signed-in devices and it is possible that multiple = devices answer to the session. Here, user may move from one device = (mobile) to another device (desktop) within the session and wishes to = continue the session with the last answer. Please note that website is = flexible to provide this service. > 2) RFC 3261 SIP UA offer/answer handling w.r.t INVITE with SDP to = multiple 2xx with SDP handling scenario using JSEP > 3) Another SIP usecase could be multiple 18x responses with SDP = for INVITE with SDP and multiple 2xx responses without SDP but order = within 18x and 200 are not same. Say 2xx of the second 18x is received = as the first 2xx. Here, we need to know how second 18x is handled and = also, the subsequent 2xx is handled. > =20 > Of course, it is possible to build more usecases around this area. As = we made signaling outside the scope of WebRTC, it is upto JS application = to decide the order in which offer/answer happens. I=92m not relating = offer/answer FSM with session establishment state like 18x, 2xx but I=92m = interested in knowing browser media plane behavior in different state of = offer/answer handling by which JS application behaves consistently in = all browsers. > =20 > Thanks > Partha > =20 > =20 > From: Justin Uberti [mailto:juberti@google.com]=20 > Sent: Tuesday, February 14, 2012 11:36 PM > To: Ravindran, Parthasarathi > Cc: rtcweb@ietf.org; public-webrtc@w3.org > Subject: Re: Single offer with multiple answer handling in JSEP [was = RE: [rtcweb] New JSEP draft posted] > =20 > Partha, > =20 > I need more information about the use case to provide an accurate = response. As mentioned in my earlier mail, are both answers 2xx = responses? >=20 > On Tue, Feb 14, 2012 at 12:17 PM, Ravindran, Parthasarathi = wrote: > Hi Justin, > =20 > In this mail thread, Let us define the behavior of multiple (atleast = two) answers for the single offer in WebRTC browser. Now, Please let me = know your opinion for my below mail. > =20 > Thanks > Partha > =20 > From: Justin Uberti [mailto:juberti@google.com]=20 > Sent: Tuesday, February 14, 2012 9:47 PM >=20 > To: Ravindran, Parthasarathi > Cc: rtcweb@ietf.org; public-webrtc@w3.org > Subject: Re: Single offer with multiple answer handling in JSEP [was = RE: [rtcweb] New JSEP draft posted] > =20 > =20 >=20 > On Tue, Feb 14, 2012 at 6:39 AM, Ravindran, Parthasarathi = wrote: > Hi Justin, > =20 > It will be good to mention in the JSEP draft that multiple answers = for single offer will not lead to RTP Mixing and WebRTC client acts as = RTP Endpoint. > =20 > Failing the second Answer will be limiting the provision in RFC 3264 = offer/answer itself as RFC 3264 supports single offer with multiple = answer. Also, it is better to define the behavior in API rather than = putting this scenario in the browser implementation specific. In simple = scenarios (like alerting with one answer, connect with second answer), = replacing the previous ANSWER will be expected behavior. This may not be = desired behavior in case two connect responses from different WebRTC = clients received with different answers but there is no other = alternative solution possible without mixing. > =20 > Do you need to support 2 final answers, or would the provisional = answer support provided via SDP_PRANSWER work for you? > =20 > IMO, it is better to define it explicitly in JSEP that =93latest = ANSWER to the offer will replace the existing answer is the expected = behavior =94. Also, Please mentioned that JS application is responsible = for discarding (terminating) previous ANSWER notification. Please let = me your opinion on this closure. > =20 > Thanks > Partha > =20 > From: Justin Uberti [mailto:juberti@google.com]=20 > Sent: Tuesday, February 14, 2012 7:29 PM > To: Ravindran, Parthasarathi > Cc: rtcweb@ietf.org; public-webrtc@w3.org > Subject: Re: Single offer with multiple answer handling in JSEP [was = RE: [rtcweb] New JSEP draft posted] > =20 > Regarding your previous mail, an ANSWER after an ANSWER would either = fail (if we wanted to simplify), or replace the previous ANSWER = (essentially the same as if you had done setLocalDescription(OFFER, = localDescription) followed by setRemoteDescription(ANSWER, answer2). > =20 > In no case would it mix the descriptions/media from both answers. > =20 > Other comments inline below. >=20 > On Tue, Feb 14, 2012 at 1:24 AM, Ravindran, Parthasarathi = wrote: > Hi Justin, > =20 > Adding to my earlier mail, In case answer2 SDP is updated in offerer1 = browser without notifying answerer1, then answer1 will continue to = transmit RTP which may not be desired behavior. IMO, we need to define = this behavior clearly in offerer side. Some of the possible solutions = are > =20 > 1) offerer1 has to send atleast RTCP BYE packets towards = answerer1 while accepting the answerer2 SDP.=20 >=20 > 2) Throw callback to clear answer1 SDP towards offererJS. >=20 > =20 > The application which called setRemoteDescription twice should have = the best idea about what is going on, and therefore is responsible for = notifying answerer1 that its answer has been discarded, if it makes = sense to do so. No callback should be needed here.=20 > =20 >=20 > Please let me know your opinion here. > =20 > Thanks > Partha > =20 > From: Ravindran, Parthasarathi=20 > Sent: Tuesday, February 14, 2012 12:07 AM > To: 'Justin Uberti'; rtcweb@ietf.org; public-webrtc@w3.org > Subject: Single offer with multiple answer handling in JSEP [was RE: = [rtcweb] New JSEP draft posted] > =20 > Hi Justin, > =20 > In the draft, it is not spelled out explicitly what is the expected = behavior in offerer browser in case multiple answer is received for = single offer. Offer/answer exchange in offerer is as follows: > =20 > OffererJS->OffererUA: var offer =3D pc.createOffer(null); > OffererJS->OffererUA: pc.setLocalDescription(SDP_OFFER, offer); > OffererJS->OffererUA: pc.setRemoteDescription(SDP_ANSWER, answer1); > OffererUA->Answerer1UA: > OffererJS->OffererUA: pc.setRemoteDescription(SDP_ANSWER, answer2); > OffererUA->Answerer?UA: ? > =20 > My understanding is that =93answer2=94 will update =93answer1=94 in = browser and starting sending/receiving media towards answer2 media IP = and port. Could you please explain the expected behavior in offerer = browser whether it updates the media stream based on the last answer or = mixes both answerer. > =20 > Thanks > Partha > =20 > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On = Behalf Of Justin Uberti > Sent: Thursday, February 09, 2012 2:27 AM > To: rtcweb@ietf.org; public-webrtc@w3.org > Subject: [rtcweb] New JSEP draft posted > =20 > Now available at = http://www.ietf.org/id/draft-uberti-rtcweb-jsep-01.txt > =20 > Includes changes based on implementation feedback, and I believe it = addresses most of the concerns raised in last week's interim meetings: > - Initial documentation provided for each API call, and what state = changes it causes > - More examples, including a complete basic sample application > - Simplified approach to trickle candidate handling > - Resolved concerns about how to separate SDP attributes into media / = transport > - Provided encapsulation for SDP blobs and ICE candidate lines, in the = event we want to change encodings or provide helper functions for JS > - Provided mechanism for limiting candidates to TURN-only > - Resolved several implementation issues > =20 > I have not yet addressed the non-overlapping codec concern mentioned = in the interim meeting. I think there are ways of handling this either = in the application or the implementation, but I wanted to get this -01 = out first for feedback. > =20 > =20 > =20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From pravindran@sonusnet.com Wed Feb 15 01:13: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 E9C3A21F8634 for ; Wed, 15 Feb 2012 01:13:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovEBIGsO6X10 for ; Wed, 15 Feb 2012 01:13:35 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 311A621F8633 for ; Wed, 15 Feb 2012 01:13:27 -0800 (PST) Received: from sonusmail06.sonusnet.com (sonusmail06.sonusnet.com [10.128.32.156]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q1F9EBeG031397; Wed, 15 Feb 2012 04:14:11 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail06.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 15 Feb 2012 04:13:23 -0500 Received: from INBA-HUB02.sonusnet.com ([10.70.51.87]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 15 Feb 2012 14:43:32 +0530 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, 15 Feb 2012 14:43:32 +0530 From: "Ravindran, Parthasarathi" To: Cullen Jennings Thread-Topic: [rtcweb] Single offer with multiple answer handling in JSEP [was RE: New JSEP draft posted] Thread-Index: AQHM67gG55cr02A1XECJjPr/R3Q48ZY9oafA Date: Wed, 15 Feb 2012 09:13:31 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E03FD85@inba-mail01.sonusnet.com> References: <387F9047F55E8C42850AD6B3A7A03C6C0E03F8A4@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E03FAB5@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E03FB7C@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E03FC20@inba-mail01.sonusnet.com> <9ED4A9AC-37C7-4E6D-B6C6-4D3C9537B356@iii.ca> In-Reply-To: <9ED4A9AC-37C7-4E6D-B6C6-4D3C9537B356@iii.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 15 Feb 2012 09:13:32.0632 (UTC) FILETIME=[16D7B580:01CCEBC2] Cc: "public-webrtc@w3.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Single offer with multiple answer handling in JSEP [was RE: New JSEP draft posted] 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, 15 Feb 2012 09:13:40 -0000 Cullen, RFC3261 references for receiving multiple 2xx in UAC which does not fork IN= VITE are as follows: Sec 13.1 Para 3: Therefore, when multiple 2xx responses are received from different remote U= As (because the INVITE forked), each 2xx establishes a different dialog. A= ll these dialogs are part of the same call. Sec 13.2.2.4 2xx Responses Multiple 2xx responses may arrive at the UAC for a single INVITE request due to a forking proxy. Each response is distinguished by the tag parameter in the To header field, and each represents a distinct dialog, with a distinct dialog identifier. If, after acknowledging any 2xx response to an INVITE, the UAC does not want to continue with that dialog, then the UAC MUST terminate the dialog by sending a BYE request as described in Section 15. =20 As per the last statements, it is upto the SIP application to decide which = one of the final 2xx response has to be included within the call. The useca= se 3 is based on RFC3262 (PRACK) support wherein it is possible to receive = multiple forked 18x with SDP followed by 2xx with or without SDP and SIP 2x= x response is not tied to offer/answer exchange.=20 I have provided mobile to desktop as an example to justify the last answer = may be used in the offer in some JS application. As I mentioned below, ther= e is no need to restrict updating latest answer for an offer in terms of AP= I and protocol.=20 Thanks Partha >-----Original Message----- >From: Cullen Jennings [mailto:fluffy@iii.ca] >Sent: Wednesday, February 15, 2012 1:31 PM >To: Ravindran, Parthasarathi >Cc: Justin Uberti; rtcweb@ietf.org; public-webrtc@w3.org >Subject: Re: [rtcweb] Single offer with multiple answer handling in JSEP >[was RE: New JSEP draft posted] > > >I'm a bit lost on use case in SIP context - assuming that the UAC did >not fork but that a proxy or B2BUA did the forking, it seems like the >UAC should never receive more than one final response. > >In the case of moving from desktop to mobile, it seems like that is >updating the stream and would use a call flow more like update examples >in the draft instead of trying to reuse some old answer. > > >On Feb 14, 2012, at 11:24 , Ravindran, Parthasarathi wrote: > >> Justin, >> >> Some of the usecases could be >> 1) The same user of a website signed-in in the multiples devices >and acts as answerer, the session establishment request to the identity >will alert all the signed-in devices and it is possible that multiple >devices answer to the session. Here, user may move from one device >(mobile) to another device (desktop) within the session and wishes to >continue the session with the last answer. Please note that website is >flexible to provide this service. >> 2) RFC 3261 SIP UA offer/answer handling w.r.t INVITE with SDP to >multiple 2xx with SDP handling scenario using JSEP >> 3) Another SIP usecase could be multiple 18x responses with SDP >for INVITE with SDP and multiple 2xx responses without SDP but order >within 18x and 200 are not same. Say 2xx of the second 18x is received >as the first 2xx. Here, we need to know how second 18x is handled and >also, the subsequent 2xx is handled. >> >> Of course, it is possible to build more usecases around this area. As >we made signaling outside the scope of WebRTC, it is upto JS application >to decide the order in which offer/answer happens. I'm not relating >offer/answer FSM with session establishment state like 18x, 2xx but I'm >interested in knowing browser media plane behavior in different state of >offer/answer handling by which JS application behaves consistently in >all browsers. >> >> Thanks >> Partha >> >> >> From: Justin Uberti [mailto:juberti@google.com] >> Sent: Tuesday, February 14, 2012 11:36 PM >> To: Ravindran, Parthasarathi >> Cc: rtcweb@ietf.org; public-webrtc@w3.org >> Subject: Re: Single offer with multiple answer handling in JSEP [was >RE: [rtcweb] New JSEP draft posted] >> >> Partha, >> >> I need more information about the use case to provide an accurate >response. As mentioned in my earlier mail, are both answers 2xx >responses? >> >> On Tue, Feb 14, 2012 at 12:17 PM, Ravindran, Parthasarathi > wrote: >> Hi Justin, >> >> In this mail thread, Let us define the behavior of multiple (atleast >two) answers for the single offer in WebRTC browser. Now, Please let me >know your opinion for my below mail. >> >> Thanks >> Partha >> >> From: Justin Uberti [mailto:juberti@google.com] >> Sent: Tuesday, February 14, 2012 9:47 PM >> >> To: Ravindran, Parthasarathi >> Cc: rtcweb@ietf.org; public-webrtc@w3.org >> Subject: Re: Single offer with multiple answer handling in JSEP [was >RE: [rtcweb] New JSEP draft posted] >> >> >> >> On Tue, Feb 14, 2012 at 6:39 AM, Ravindran, Parthasarathi > wrote: >> Hi Justin, >> >> It will be good to mention in the JSEP draft that multiple answers >for single offer will not lead to RTP Mixing and WebRTC client acts as >RTP Endpoint. >> >> Failing the second Answer will be limiting the provision in RFC 3264 >offer/answer itself as RFC 3264 supports single offer with multiple >answer. Also, it is better to define the behavior in API rather than >putting this scenario in the browser implementation specific. In simple >scenarios (like alerting with one answer, connect with second answer), >replacing the previous ANSWER will be expected behavior. This may not be >desired behavior in case two connect responses from different WebRTC >clients received with different answers but there is no other >alternative solution possible without mixing. >> >> Do you need to support 2 final answers, or would the provisional >answer support provided via SDP_PRANSWER work for you? >> >> IMO, it is better to define it explicitly in JSEP that "latest ANSWER >to the offer will replace the existing answer is the expected behavior >". Also, Please mentioned that JS application is responsible for >discarding (terminating) previous ANSWER notification. Please let me >your opinion on this closure. >> >> Thanks >> Partha >> >> From: Justin Uberti [mailto:juberti@google.com] >> Sent: Tuesday, February 14, 2012 7:29 PM >> To: Ravindran, Parthasarathi >> Cc: rtcweb@ietf.org; public-webrtc@w3.org >> Subject: Re: Single offer with multiple answer handling in JSEP [was >RE: [rtcweb] New JSEP draft posted] >> >> Regarding your previous mail, an ANSWER after an ANSWER would either >fail (if we wanted to simplify), or replace the previous ANSWER >(essentially the same as if you had done setLocalDescription(OFFER, >localDescription) followed by setRemoteDescription(ANSWER, answer2). >> >> In no case would it mix the descriptions/media from both answers. >> >> Other comments inline below. >> >> On Tue, Feb 14, 2012 at 1:24 AM, Ravindran, Parthasarathi > wrote: >> Hi Justin, >> >> Adding to my earlier mail, In case answer2 SDP is updated in offerer1 >browser without notifying answerer1, then answer1 will continue to >transmit RTP which may not be desired behavior. IMO, we need to define >this behavior clearly in offerer side. Some of the possible solutions >are >> >> 1) offerer1 has to send atleast RTCP BYE packets towards >answerer1 while accepting the answerer2 SDP. >> >> 2) Throw callback to clear answer1 SDP towards offererJS. >> >> >> The application which called setRemoteDescription twice should have >the best idea about what is going on, and therefore is responsible for >notifying answerer1 that its answer has been discarded, if it makes >sense to do so. No callback should be needed here. >> >> >> Please let me know your opinion here. >> >> Thanks >> Partha >> >> From: Ravindran, Parthasarathi >> Sent: Tuesday, February 14, 2012 12:07 AM >> To: 'Justin Uberti'; rtcweb@ietf.org; public-webrtc@w3.org >> Subject: Single offer with multiple answer handling in JSEP [was RE: >[rtcweb] New JSEP draft posted] >> >> Hi Justin, >> >> In the draft, it is not spelled out explicitly what is the expected >behavior in offerer browser in case multiple answer is received for >single offer. Offer/answer exchange in offerer is as follows: >> >> OffererJS->OffererUA: var offer =3D pc.createOffer(null); >> OffererJS->OffererUA: pc.setLocalDescription(SDP_OFFER, offer); >> OffererJS->OffererUA: pc.setRemoteDescription(SDP_ANSWER, answer1); >> OffererUA->Answerer1UA: >> OffererJS->OffererUA: pc.setRemoteDescription(SDP_ANSWER, answer2); >> OffererUA->Answerer?UA: ? >> >> My understanding is that "answer2" will update "answer1" in browser >and starting sending/receiving media towards answer2 media IP and port. >Could you please explain the expected behavior in offerer browser >whether it updates the media stream based on the last answer or mixes >both answerer. >> >> Thanks >> Partha >> >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >Behalf Of Justin Uberti >> Sent: Thursday, February 09, 2012 2:27 AM >> To: rtcweb@ietf.org; public-webrtc@w3.org >> Subject: [rtcweb] New JSEP draft posted >> >> Now available at http://www.ietf.org/id/draft-uberti-rtcweb-jsep- >01.txt >> >> Includes changes based on implementation feedback, and I believe it >addresses most of the concerns raised in last week's interim meetings: >> - Initial documentation provided for each API call, and what state >changes it causes >> - More examples, including a complete basic sample application >> - Simplified approach to trickle candidate handling >> - Resolved concerns about how to separate SDP attributes into media / >transport >> - Provided encapsulation for SDP blobs and ICE candidate lines, in the >event we want to change encodings or provide helper functions for JS >> - Provided mechanism for limiting candidates to TURN-only >> - Resolved several implementation issues >> >> I have not yet addressed the non-overlapping codec concern mentioned >in the interim meeting. I think there are ways of handling this either >in the application or the implementation, but I wanted to get this -01 >out first for feedback. >> >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb From christer.holmberg@ericsson.com Wed Feb 15 02:47: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 2A24621F858E for ; Wed, 15 Feb 2012 02:47:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.523 X-Spam-Level: X-Spam-Status: No, score=-9.523 tagged_above=-999 required=5 tests=[AWL=1.075, 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 QzJ6e3my7Wph for ; Wed, 15 Feb 2012 02:47:47 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 014D721F8505 for ; Wed, 15 Feb 2012 02:47:44 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-f4-4f3b8d4f0d45 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 89.10.27041.F4D8B3F4; Wed, 15 Feb 2012 11:47:44 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Wed, 15 Feb 2012 11:47:43 +0100 From: Christer Holmberg To: "rtcweb@ietf.org" , "public-webrtc@w3.org" Date: Wed, 15 Feb 2012 11:47:42 +0100 Thread-Topic: JSEP-01: SDP_PRANSWER and FEDEX use-case Thread-Index: Aczrzz6XG3Vy2hSmQYSRG7sNMuPXaQ== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3D87E060@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: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A05852C3D87E060ESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [rtcweb] JSEP-01: SDP_PRANSWER and FEDEX use-case 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, 15 Feb 2012 10:47:48 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A05852C3D87E060ESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Section 6.1.4 of jsep-01 says: "SDP_PRANSWER indicates that a description should be parsed as an answer, but not a final answer, and so should not result in the starting of media transmission. A description used as a SDP_PRANSWE= R may be applied as a response to a SDP_OFFER, or an update to a previously sent SDP_PRANSWER." Section 7.6 shows a SIP early media (FEDEX) use-case, where an SDP answer r= eceived in a SIP 18x response is provided to the browser as a SDP_PRANSWER. Q1: Since SDP_PRANSWER is not supposed to start media transmission, how wil= l the use-case work? As far as I know, media transmission is needed for the= FEDEX use-case. Q2: The draft doesn't really specify what SDP_PRANSWER is used for. I under= stand that it means that a "final" answer may be provided later, but it doe= sn't really say what the a browser would do with an SDP_PRANSWER - especial= ly since it doesn't seem to enable media. Q3: Assuming we would allow multiple SDP_ANSWER (see separate thread), is t= here a need for SDP_PRANSWER? Regards, Christer --_000_7F2072F1E0DE894DA4B517B93C6A05852C3D87E060ESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
Section 6.1.4 of jsep-01 says:
 
        "SDP_= PRANSWER indicates that a description should be parsed as an
         answ= er, but not a final answer, and so should not result in the
         star= ting of media transmission. A description used as a SDP_PRANSWER
         may = be applied as a response to a SDP_OFFER, or an update to a
         prev= iously sent SDP_PRANSWER."
 
 
Section 7.6 shows a SIP early media (FEDEX) use-case,= where an SDP answer received in a SIP 18x response is provided to the brow= ser as a SDP_PRANSWER.
 
 
Q1: Since SDP_PRANSWER is not supposed to start media= transmission, how will the use-case work? As far as I know, media transmis= sion is needed for the FEDEX use-case.
 
Q2: The draft doesn't really specify what SDP_PRANSWE= R is used for. I understand that it means that a "final" answer m= ay be provided later, but it doesn't really say what the a browser would do= with an SDP_PRANSWER - especially since it doesn't seem to enable media.
 
Q3: Assuming we would allow multiple SDP_ANSWER (see = separate thread), is there a need for SDP_PRANSWER?
 
Regards,
 
Christer
 
 
 --_000_7F2072F1E0DE894DA4B517B93C6A05852C3D87E060ESESSCMS0356e_-- From christer.holmberg@ericsson.com Wed Feb 15 02:56: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 D5BD921F8773 for ; Wed, 15 Feb 2012 02:56:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.265 X-Spam-Level: X-Spam-Status: No, score=-9.265 tagged_above=-999 required=5 tests=[AWL=0.733, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPW8op259Ovu for ; Wed, 15 Feb 2012 02:56:11 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 148C921F86E0 for ; Wed, 15 Feb 2012 02:56:10 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-3f-4f3b8f49f708 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 8D.05.01970.94F8B3F4; Wed, 15 Feb 2012 11:56:10 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 15 Feb 2012 11:56:09 +0100 From: Christer Holmberg To: "rtcweb@ietf.org" , "public-webrtc@w3.org" Date: Wed, 15 Feb 2012 11:56:08 +0100 Thread-Topic: JSEP-01: Associating ICE candidates with m- lines Thread-Index: Aczr0GxEPBe0pjLESs6nUGf9EGtrgQ== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3D87E075@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: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A05852C3D87E075ESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [rtcweb] JSEP-01: Associating ICE candidates with m- lines 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, 15 Feb 2012 10:56:11 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A05852C3D87E075ESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, In jsep-01, an "m- line reference" has been added to the a=3Dcandidate attr= ibute, in order for the browser to indicate for which m- line the attribute= belongs to. Q1: As, within a session, as new SDP offers may be sent (and, as least in t= heory I assume, new local candidates may be provided), I wonder whether it,= in addition to the m- line reference, also would be useful to include an S= DP version reference (found the SDP o- line)? Q2: If BUNDLE is used, multiple m- lines may share the same candidates, so = it should be possible to indicate that an a=3Dcandidate attribute belongs t= o multiple m- lines - AND/OR to indicate that it belongs to a given bundle = group. Regards, Christer --_000_7F2072F1E0DE894DA4B517B93C6A05852C3D87E075ESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
In jsep-01, an "m- line reference" has been= added to the a=3Dcandidate attribute, in order for the browser to indicate= for which m- line the attribute belongs to.
 
Q1: As, within a session, as new SDP offers may be se= nt (and, as least in theory I assume, new local candidates may be provided)= , I wonder whether it, in addition to the m- line reference, also would be = useful to include an SDP version reference (found the SDP o- line)?
 
Q2: If BUNDLE is used, multiple m- lines may share th= e same candidates, so it should be possible to indicate that an a=3Dcandida= te attribute belongs to multiple m- lines - AND/OR to indicate that it belo= ngs to a given bundle group.
 
Regards,
 
Christer
 
 --_000_7F2072F1E0DE894DA4B517B93C6A05852C3D87E075ESESSCMS0356e_-- From pravindran@sonusnet.com Wed Feb 15 02: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 D9E9E21F8779 for ; Wed, 15 Feb 2012 02:56:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RuukLJzLCKOa for ; Wed, 15 Feb 2012 02:56:17 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE6321F8778 for ; Wed, 15 Feb 2012 02:56:16 -0800 (PST) Received: from sonusmail06.sonusnet.com (sonusmail06.sonusnet.com [10.128.32.156]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q1FAv0MB000839; Wed, 15 Feb 2012 05:57:00 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail06.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 15 Feb 2012 05:56:12 -0500 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 15 Feb 2012 16:26:21 +0530 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, 15 Feb 2012 16:26:20 +0530 From: "Ravindran, Parthasarathi" To: Christer Holmberg , "rtcweb@ietf.org" , "public-webrtc@w3.org" Thread-Topic: JSEP-01: SDP_PRANSWER and FEDEX use-case Thread-Index: Aczrzz6XG3Vy2hSmQYSRG7sNMuPXaQAAIBXQ Date: Wed, 15 Feb 2012 10:56:20 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E03FE33@inba-mail01.sonusnet.com> References: <7F2072F1E0DE894DA4B517B93C6A05852C3D87E060@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3D87E060@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: multipart/alternative; boundary="_000_387F9047F55E8C42850AD6B3A7A03C6C0E03FE33inbamail01sonus_" MIME-Version: 1.0 X-OriginalArrivalTime: 15 Feb 2012 10:56:21.0391 (UTC) FILETIME=[73B5A1F0:01CCEBD0] Subject: Re: [rtcweb] JSEP-01: SDP_PRANSWER and FEDEX use-case 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, 15 Feb 2012 10:56:18 -0000 --_000_387F9047F55E8C42850AD6B3A7A03C6C0E03FE33inbamail01sonus_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Christer, I agree with you that SDP_PRANSWER is not need in case multiple answer is s= upported. Thanks Partha From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Christer Holmberg Sent: Wednesday, February 15, 2012 4:18 PM To: rtcweb@ietf.org; public-webrtc@w3.org Subject: [rtcweb] JSEP-01: SDP_PRANSWER and FEDEX use-case Hi, Section 6.1.4 of jsep-01 says: "SDP_PRANSWER indicates that a description should be parsed as an answer, but not a final answer, and so should not result in the starting of media transmission. A description used as a SDP_PRANSW= ER may be applied as a response to a SDP_OFFER, or an update to a previously sent SDP_PRANSWER." Section 7.6 shows a SIP early media (FEDEX) use-case, where an SDP answer r= eceived in a SIP 18x response is provided to the browser as a SDP_PRANSWER. Q1: Since SDP_PRANSWER is not supposed to start media transmission, how wil= l the use-case work? As far as I know, media transmission is needed for the= FEDEX use-case. Q2: The draft doesn't really specify what SDP_PRANSWER is used for. I under= stand that it means that a "final" answer may be provided later, but it doe= sn't really say what the a browser would do with an SDP_PRANSWER - especial= ly since it doesn't seem to enable media. Q3: Assuming we would allow multiple SDP_ANSWER (see separate thread), is t= here a need for SDP_PRANSWER? Regards, Christer --_000_387F9047F55E8C42850AD6B3A7A03C6C0E03FE33inbamail01sonus_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Christer,

 <= /p>

I agree with you that SDP= _PRANSWER is not need in case multiple answer is supported.

 <= /p>

Thanks<= /p>

Partha<= /p>

 <= /p>

From: rtcweb-b= ounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: Wednesday, February 15, 2012 4:18 PM
To: rtcweb@ietf.org; public-webrtc@w3.org
Subject: [rtcweb] JSEP-01: SDP_PRANSWER and FEDEX use-case

 

 

Hi,

 

Section 6.1.4 of jsep-01 says:

 

       = ; "SDP_PRANSWER indicates that a description should be parsed as an

       = ;  answer, but not a final answer, and so should not result in the

       = ;  starting of media transmission. A description used as a SDP_PRANSWE= R

       = ;  may be applied as a response to a SDP_OFFER, or an update to a

       = ;  previously sent SDP_PRANSWER."

 

 

Section 7.6 shows a SIP early media (FEDE= X) use-case, where an SDP answer received in a SIP 18x response is provided= to the browser as a SDP_PRANSWER.

 

 

Q1: Since SDP_PRANSWER is not supposed to= start media transmission, how will the use-case work? As far as I know, me= dia transmission is needed for the FEDEX use-case.

 

Q2: The draft doesn't really specify what= SDP_PRANSWER is used for. I understand that it means that a "final&qu= ot; answer may be provided later, but it doesn't really say what the a browser would do with an SDP_PRANSWER - especially since it doesn't seem= to enable media.

 

Q3: Assuming we would allow multiple SDP_= ANSWER (see separate thread), is there a need for SDP_PRANSWER?=

 

Regards,

 

Christer

 

 

--_000_387F9047F55E8C42850AD6B3A7A03C6C0E03FE33inbamail01sonus_-- From christer.holmberg@ericsson.com Wed Feb 15 06:26: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 C70E021F8776 for ; Wed, 15 Feb 2012 06:26:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.592 X-Spam-Level: X-Spam-Status: No, score=-9.592 tagged_above=-999 required=5 tests=[AWL=1.006, 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 BUXMZGYyC-bw for ; Wed, 15 Feb 2012 06:26:34 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 09EEF21F875A for ; Wed, 15 Feb 2012 06:26:33 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-b5-4f3bc0986731 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 67.FB.01970.890CB3F4; Wed, 15 Feb 2012 15:26:33 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Wed, 15 Feb 2012 15:26:32 +0100 From: Christer Holmberg To: "rtcweb@ietf.org" , "public-webrtc@w3.org" Date: Wed, 15 Feb 2012 15:26:30 +0100 Thread-Topic: JSEP-01: Release of non-needed ICE candidates Thread-Index: Aczr7c+ci4urS+pvQA6c/g6DIJgXSQ== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3D87E29E@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: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A05852C3D87E29EESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [rtcweb] JSEP-01: Release of non-needed ICE candidates 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, 15 Feb 2012 14:26:34 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A05852C3D87E29EESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Assume my SIP JS app gets an offer, and some ICE candidatates, generates an= d sends a SIP SDP offer. Later, the browser provides additional ICE candidates (using the ice callba= ck function). My SIP JS app is not interested in the additional ICE candidates. Q1: Is it possible for the JS app to inform the browser that it does not ne= ed the additional ICE candidates? For example, if my app is given turn cand= idates, which I am not going to use (read: offer to the remote party), ther= e is really no need for the browser to maintain the connection with the tur= n server. Q2: Do we assume that the browser at some point (e.g. when the associated a= nswer is provided) will be able to release resources associated with non-ne= eded ICE candidates? Regards, Christer --_000_7F2072F1E0DE894DA4B517B93C6A05852C3D87E29EESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
Assume my SIP JS app gets an offer, and some ICE cand= idatates, generates and sends a SIP SDP offer.
 
Later, the browser provides additional ICE candidates= (using the ice callback function).
 
My SIP JS app is not interested in the additional ICE= candidates.
 
Q1: Is it possible for the JS app to inform the brows= er that it does not need the additional ICE candidates? For example, if my = app is given turn candidates, which I am not going to use (read: offer to t= he remote party), there is really no need for the browser to maintain the connection with the turn server.
 
Q2: Do we assume that the browser at some point (e.g.= when the associated answer is provided) will be able to release resources = associated with non-needed ICE candidates?
 
Regards,
 
Christer
 
 --_000_7F2072F1E0DE894DA4B517B93C6A05852C3D87E29EESESSCMS0356e_-- From christer.holmberg@ericsson.com Wed Feb 15 09: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 1DA6421F874C for ; Wed, 15 Feb 2012 09:31:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.628 X-Spam-Level: X-Spam-Status: No, score=-9.628 tagged_above=-999 required=5 tests=[AWL=0.971, 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 rQwZjsPnCtd0 for ; Wed, 15 Feb 2012 09:31:47 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 44EA321F86DB for ; Wed, 15 Feb 2012 09:31:47 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-90-4f3bec02e90d Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 1A.19.01970.20CEB3F4; Wed, 15 Feb 2012 18:31:46 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 15 Feb 2012 18:31:45 +0100 From: Christer Holmberg To: Jim Barnett , "rtcweb@ietf.org" , "public-webrtc@w3.org" Date: Wed, 15 Feb 2012 18:28:29 +0100 Thread-Topic: [rtcweb] JSEP-01: Release of non-needed ICE candidates Thread-Index: Aczr7c+ci4urS+pvQA6c/g6DIJgXSQACiCiwAAPS5K0= Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3D31BA27@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C3D87E29E@ESESSCMS0356.eemea.ericsson.se>, 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 X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] JSEP-01: Release of non-needed ICE candidates 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, 15 Feb 2012 17:31:48 -0000 Hi, My use-case is not about whether the app wants turn candidates or not - it = is about that fact that it at some point decides to send the SIP SDP offer = towards the remote party, even if it has not received all candidates that i= s previously specified. Maybe the browser, due to some network and/or configuration error, isn't ev= en able to contact a turn server. Will it inform the app about that, or wil= l it simply not provide turn candidates? Regards, Christer ________________________________________ From: Jim Barnett [Jim.Barnett@genesyslab.com] Sent: Wednesday, February 15, 2012 5:43 PM To: Christer Holmberg; rtcweb@ietf.org; public-webrtc@w3.org Subject: RE: [rtcweb] JSEP-01: Release of non-needed ICE candidates In section 6.1.9 of the latest JSEP draft, the startICE() function allows t= he JS app to specify which types of candidates it wants, so your app can a= void getting turn candidates in the first place. I would also assume that = the browser could/would release un-needed resources when setRemoteDescripti= on is called. - Jim From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Christer Holmberg Sent: Wednesday, February 15, 2012 9:27 AM To: rtcweb@ietf.org; public-webrtc@w3.org Subject: [rtcweb] JSEP-01: Release of non-needed ICE candidates Hi, Assume my SIP JS app gets an offer, and some ICE candidatates, generates an= d sends a SIP SDP offer. Later, the browser provides additional ICE candidates (using the ice callba= ck function). My SIP JS app is not interested in the additional ICE candidates. Q1: Is it possible for the JS app to inform the browser that it does not ne= ed the additional ICE candidates? For example, if my app is given turn cand= idates, which I am not going to use (read: offer to the remote party), ther= e is really no need for the browser to maintain the connection with the tur= n server. Q2: Do we assume that the browser at some point (e.g. when the associated a= nswer is provided) will be able to release resources associated with non-ne= eded ICE candidates? Regards, Christer From juberti@google.com Wed Feb 15 21:54: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 6003421F854F for ; Wed, 15 Feb 2012 21:54:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.729 X-Spam-Level: X-Spam-Status: No, score=-102.729 tagged_above=-999 required=5 tests=[AWL=0.247, 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 X+qycG53bzMZ for ; Wed, 15 Feb 2012 21:54:04 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5E6A521F8598 for ; Wed, 15 Feb 2012 21:54:04 -0800 (PST) Received: by iagf6 with SMTP id f6so2917399iag.31 for ; Wed, 15 Feb 2012 21:54:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:from:date:message-id:subject:to:cc:content-type :x-system-of-record; bh=UKyxDYEl1VK4ohyRSLItWaUziEP0p79sCypUq4oCF5o=; b=bQvCu99ABXvu2Mx8EyZ4VgRHghrck+fIhhN/Hv3H9VCmb9QHvnXzUPOYchMdKMtn6i uekEKj8XtlKbdVaYW33m1cnqRzuylGCDfVYeS/Jh2GkFluONA4LcsV2BUjf3nTUXJjDP zjOoAB9iQqvwrYapAXyyFBONe5yqQmMzI5/Rs= Received: by 10.42.74.72 with SMTP id v8mr743403icj.14.1329371642330; Wed, 15 Feb 2012 21:54:02 -0800 (PST) Received: by 10.42.74.72 with SMTP id v8mr743396icj.14.1329371642251; Wed, 15 Feb 2012 21:54:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.9.8 with HTTP; Wed, 15 Feb 2012 21:53:42 -0800 (PST) From: Justin Uberti Date: Thu, 16 Feb 2012 00:53:42 -0500 Message-ID: To: public-webrtc@w3.org, rtcweb@ietf.org Content-Type: multipart/alternative; boundary=90e6ba3fd60d82cb6804b90e74cf X-System-Of-Record: true X-Gm-Message-State: ALoCoQl6CcjagFWkmT38QFZ29BL2N/bnV8+e/mLO1OvdRjaljqB0NGwmQNfqL65kkLfvR60vJ5YlCXrzmjehTn3U1ZGDHA4TwR0fjvBpiNV2sifcH0wVYaTgObxlD4K0sEKGLjXI2dbaHomOPCWXug+QZYhWpRjgdA== Cc: "Cullen Jennings \(fluffy\)" Subject: [rtcweb] Joint JSEP draft posted 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, 16 Feb 2012 05:54:10 -0000 --90e6ba3fd60d82cb6804b90e74cf Content-Type: text/plain; charset=UTF-8 I've just uploaded a -02 version of the JSEP draft, to which Cullen Jennings has agreed to sign on as a co-author. This draft includes a few specific changes suggested by Cullen to ensure that JSEP can be used to create applications that are RFC 3264-compliant, if desired. The draft is available at http://tools.ietf.org/html/draft-uberti-rtcweb-jsep-02. Please refer to this latest version of the document when responding to the JSEP call for consensus. Best regards, --justin --90e6ba3fd60d82cb6804b90e74cf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I've just uploaded a -02 version of the JSEP draft, to which Cullen Jen= nings has agreed to sign on as a co-author. This draft includes a few speci= fic changes suggested by Cullen to ensure that JSEP can be used to create a= pplications that are RFC 3264-compliant, if desired.=C2=A0

The draft is available at=C2=A0http://tools.ietf.org/html/draft-uber= ti-rtcweb-jsep-02.=C2=A0Please refer to this latest version of the docu= ment when responding to the JSEP call for consensus.

Best regards,
--justin

--90e6ba3fd60d82cb6804b90e74cf-- From fluffy@iii.ca Wed Feb 15 22:22: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 3C52D21F84FD for ; Wed, 15 Feb 2012 22:22:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.864 X-Spam-Level: X-Spam-Status: No, score=-2.864 tagged_above=-999 required=5 tests=[AWL=-0.265, 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 cd-3Ay8DQYnO for ; Wed, 15 Feb 2012 22:22:24 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 2E02E11E8076 for ; Wed, 15 Feb 2012 22:22:24 -0800 (PST) Received: from sjc-vpn6-1010.cisco.com (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 411FF22E256; Thu, 16 Feb 2012 01:22:17 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Wed, 15 Feb 2012 22:22:16 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <5F8994E8-EE60-406A-A42E-BBA258A1BEDE@iii.ca> References: To: rtcweb@ietf.org X-Mailer: Apple Mail (2.1257) Subject: Re: [rtcweb] Joint JSEP draft posted 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, 16 Feb 2012 06:22:28 -0000 Justin and I spent a bunch of time trying to figure out what was the = important properties of JSEP and worked to preserver all of theses while = at the same time dealing with some of the concerns I had previously = around we were defining something that would take a long time to define. = I very happy with this version as I think it can meet a wide range of = needs and move forward quickly. On Feb 15, 2012, at 21:53 , Justin Uberti wrote: > I've just uploaded a -02 version of the JSEP draft, to which Cullen = Jennings has agreed to sign on as a co-author. This draft includes a few = specific changes suggested by Cullen to ensure that JSEP can be used to = create applications that are RFC 3264-compliant, if desired.=20 >=20 > The draft is available at = http://tools.ietf.org/html/draft-uberti-rtcweb-jsep-02. Please refer to = this latest version of the document when responding to the JSEP call for = consensus. >=20 > Best regards, > --justin >=20 From christer.holmberg@ericsson.com Wed Feb 15 22:22: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 C198221F851E for ; Wed, 15 Feb 2012 22:22:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.661 X-Spam-Level: X-Spam-Status: No, score=-9.661 tagged_above=-999 required=5 tests=[AWL=0.937, 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 V7vmC6IqDJ8W for ; Wed, 15 Feb 2012 22:22:50 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 4BBFC21F851C for ; Wed, 15 Feb 2012 22:22:49 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-c6-4f3ca0b8d1a9 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id DF.4F.01970.8B0AC3F4; Thu, 16 Feb 2012 07:22:48 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Thu, 16 Feb 2012 07:22:48 +0100 From: Christer Holmberg To: Justin Uberti , "public-webrtc@w3.org" , "rtcweb@ietf.org" Date: Thu, 16 Feb 2012 07:22:48 +0100 Thread-Topic: [rtcweb] Joint JSEP draft posted Thread-Index: Aczsb2qLGbhjXaQrQgKh9vfKPQSI1wAA7tmg Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3D87E4E7@ESESSCMS0356.eemea.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A05852C3D87E4E7ESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "Cullen Jennings \(fluffy\)" Subject: Re: [rtcweb] Joint JSEP draft posted 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, 16 Feb 2012 06:22:54 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A05852C3D87E4E7ESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Yesterday I sent out some questions on jsep-01, and I do believe they apply= also to -02. JSEP-01: SDP_PRANSWER and FEDEX use-case JSEP-01: Associating ICE candidates with m- lines JSEP-01: Release of non-needed ICE candidates Regards, Christer ________________________________ From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Justin Uberti Sent: 16. helmikuuta 2012 7:54 To: public-webrtc@w3.org; rtcweb@ietf.org Cc: Cullen Jennings (fluffy) Subject: [rtcweb] Joint JSEP draft posted I've just uploaded a -02 version of the JSEP draft, to which Cullen Jenning= s has agreed to sign on as a co-author. This draft includes a few specific = changes suggested by Cullen to ensure that JSEP can be used to create appli= cations that are RFC 3264-compliant, if desired. The draft is available at http://tools.ietf.org/html/draft-uberti-rtcweb-js= ep-02. Please refer to this latest version of the document when responding = to the JSEP call for consensus. Best regards, --justin --_000_7F2072F1E0DE894DA4B517B93C6A05852C3D87E4E7ESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
Yesterday I sent out some questions on jsep-01, an= d I do=20 believe they apply also to -02.
 
JSEP-01: SDP_PRANSWER and FEDEX=20 use-case
JSEP-01: Associating ICE candidates with m-=20 lines
JSEP-01: Release of non-needed ICE=20 candidates
 
Regards,
 
Christer

From: rtcweb-bounces@ietf.org=20 [mailto:rtcweb-bounces@ietf.org] On Behalf Of Justin=20 Uberti
Sent: 16. helmikuuta 2012 7:54
To:=20 public-webrtc@w3.org; rtcweb@ietf.org
Cc: Cullen Jennings=20 (fluffy)
Subject: [rtcweb] Joint JSEP draft=20 posted

I've just uploaded a -02 version of the JSEP draft, to which Cul= len=20 Jennings has agreed to sign on as a co-author. This draft includes a few=20 specific changes suggested by Cullen to ensure that JSEP can be used to cre= ate=20 applications that are RFC 3264-compliant, if desired. 

The draft is available at http://tool= s.ietf.org/html/draft-uberti-rtcweb-jsep-02. Please=20 refer to this latest version of the document when responding to the JSEP ca= ll=20 for consensus.

Best regards,
--justin

--_000_7F2072F1E0DE894DA4B517B93C6A05852C3D87E4E7ESESSCMS0356e_-- From fluffy@iii.ca Wed Feb 15 22:40:40 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 8886D11E8074 for ; Wed, 15 Feb 2012 22:40:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.857 X-Spam-Level: X-Spam-Status: No, score=-2.857 tagged_above=-999 required=5 tests=[AWL=-0.258, 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 onycfrn5k0wh for ; Wed, 15 Feb 2012 22:40:36 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE5611E8073 for ; Wed, 15 Feb 2012 22:40:36 -0800 (PST) Received: from sjc-vpn6-1010.cisco.com (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 7ABCD22E256; Thu, 16 Feb 2012 01:40:35 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Cullen Jennings In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3D87E060@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 15 Feb 2012 22:40:34 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <3CBDF06F-F52D-4C09-A78F-1A0D8479572A@iii.ca> References: <7F2072F1E0DE894DA4B517B93C6A05852C3D87E060@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1257) Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] JSEP-01: SDP_PRANSWER and FEDEX use-case 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, 16 Feb 2012 06:40:40 -0000 Answering for the the -02 version of jsep =85 On Feb 15, 2012, at 2:47 , Christer Holmberg wrote: > =20 > Hi, > =20 > Section 6.1.4 of jsep-01 says: > =20 > "SDP_PRANSWER indicates that a description should be parsed as = an > answer, but not a final answer, and so should not result in = the > starting of media transmission. A description used as a = SDP_PRANSWER > may be applied as a response to a SDP_OFFER, or an update to = a > previously sent SDP_PRANSWER." > =20 > =20 > Section 7.6 shows a SIP early media (FEDEX) use-case, where an SDP = answer received in a SIP 18x response is provided to the browser as a = SDP_PRANSWER. > =20 > =20 > Q1: Since SDP_PRANSWER is not supposed to start media transmission, = how will the use-case work? As far as I know, media transmission is = needed for the FEDEX use-case. Consider a browser A that implemented a protocol something like ROAP = using the JSEP API so it is going to a ROAP to SIP GW then then goes to = a GW to the PSTN that calls 1-800 go fedex.=20 The browser does a createOffer followed by setLocal with offer and sends = the offer to the ROAP to SIP GW which turns it into an INVITE with offer = to the PSTN GW. At this point the browse is listening to any media the = PSTN GW might send. The PSTN GW sends 180 with SDP that gets mapped = back to a setRemote with SDP_PRANSWER. That allows the browser and GW to = do ICE, DTLS , etc and at this point the PSTN GW can start sending media = to the browser. Given we just need 1 way media at this point, not sure = it matter much if browser sends any media or not. At the point the SIP = 200 happens, that gets mapped to a final answer. > =20 > Q2: The draft doesn't really specify what SDP_PRANSWER is used for. I = understand that it means that a "final" answer may be provided later, = but it doesn't really say what the a browser would do with an = SDP_PRANSWER - especially since it doesn't seem to enable media. I think the key thing is when the JS sets new SDP_OFFER in setLocal, it = needs to be willing to receive the old media and the media for the new = SDP. A final answers means you not longer need to to be able to receive = the media for the old SDP. A provisional offer does not allow you stop = being able to receive the media for the old SDP.=20 > =20 > Q3: Assuming we would allow multiple SDP_ANSWER (see separate thread), = is there a need for SDP_PRANSWER? >=20 > Regards, > =20 > Christer > =20 > =20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From fluffy@iii.ca Wed Feb 15 22:42: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 44E0B21F850F for ; Wed, 15 Feb 2012 22:42:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=-0.551, BAYES_00=-2.599, J_CHICKENPOX_19=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eFJUgBKSPxod for ; Wed, 15 Feb 2012 22:42:30 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 5148921F84F6 for ; Wed, 15 Feb 2012 22:42:30 -0800 (PST) Received: from sjc-vpn6-1010.cisco.com (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 90D6522E253; Thu, 16 Feb 2012 01:42:29 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3D87E075@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 15 Feb 2012 22:42:28 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7F2072F1E0DE894DA4B517B93C6A05852C3D87E075@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1257) Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] JSEP-01: Associating ICE candidates with m- lines 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, 16 Feb 2012 06:42:34 -0000 On Feb 15, 2012, at 2:56 , Christer Holmberg wrote: > =20 > Hi, > =20 > In jsep-01, an "m- line reference" has been added to the a=3Dcandidate = attribute, in order for the browser to indicate for which m- line the = attribute belongs to. > =20 > Q1: As, within a session, as new SDP offers may be sent (and, as least = in theory I assume, new local candidates may be provided), I wonder = whether it, in addition to the m- line reference, also would be useful = to include an SDP version reference (found the SDP o- line)? Seems like good idea.=20 > =20 > Q2: If BUNDLE is used, multiple m- lines may share the same = candidates, so it should be possible to indicate that an a=3Dcandidate = attribute belongs to multiple m- lines - AND/OR to indicate that it = belongs to a given bundle group. +1=20 > =20 > Regards, > =20 > Christer > =20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From fluffy@iii.ca Wed Feb 15 23:10: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 3B8D821F858F for ; Wed, 15 Feb 2012 23:10:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.836 X-Spam-Level: X-Spam-Status: No, score=-2.836 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 ArYUhQG5Gkqs for ; Wed, 15 Feb 2012 23:10:08 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id EB12021F858E for ; Wed, 15 Feb 2012 23:10:07 -0800 (PST) Received: from sjc-vpn6-1010.cisco.com (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 AB58D22E253; Thu, 16 Feb 2012 02:10:00 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E03FD85@inba-mail01.sonusnet.com> Date: Wed, 15 Feb 2012 23:09:59 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4193CA25-0266-4643-9AA2-2B99AF805944@iii.ca> References: <387F9047F55E8C42850AD6B3A7A03C6C0E03F8A4@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E03FAB5@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E03FB7C@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E03FC20@inba-mail01.sonusnet.com> <9ED4A9AC-37C7-4E6D-B6C6-4D3C9537B356@iii.ca> <387F9047F55E8C42850AD6B3A7A03C6C0E03FD85@inba-mail01.sonusnet.com> To: "Ravindran, Parthasarathi" X-Mailer: Apple Mail (2.1257) Cc: "public-webrtc@w3.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Single offer with multiple answer handling in JSEP [was RE: New JSEP draft posted] 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, 16 Feb 2012 07:10:13 -0000 Oh I see what you mean now - I was missing the different dialogs. Thanks On Feb 15, 2012, at 1:13 , Ravindran, Parthasarathi wrote: > Cullen, >=20 > RFC3261 references for receiving multiple 2xx in UAC which does not = fork INVITE are as follows: >=20 > > Sec 13.1 Para 3: >=20 > Therefore, when multiple 2xx responses are received from different = remote UAs (because the INVITE forked), each 2xx establishes a different = dialog. All these dialogs are part of the same call. >=20 > Sec 13.2.2.4 2xx Responses >=20 > Multiple 2xx responses may arrive at the UAC for a single INVITE > request due to a forking proxy. Each response is distinguished by > the tag parameter in the To header field, and each represents a > distinct dialog, with a distinct dialog identifier. >=20 > If, after acknowledging any 2xx response to an INVITE, the UAC does > not want to continue with that dialog, then the UAC MUST terminate > the dialog by sending a BYE request as described in Section 15. > =20 >=20 > As per the last statements, it is upto the SIP application to decide = which one of the final 2xx response has to be included within the call. = The usecase 3 is based on RFC3262 (PRACK) support wherein it is possible = to receive multiple forked 18x with SDP followed by 2xx with or without = SDP and SIP 2xx response is not tied to offer/answer exchange.=20 >=20 > I have provided mobile to desktop as an example to justify the last = answer may be used in the offer in some JS application. As I mentioned = below, there is no need to restrict updating latest answer for an offer = in terms of API and protocol.=20 >=20 > Thanks > Partha >=20 >> -----Original Message----- >> From: Cullen Jennings [mailto:fluffy@iii.ca] >> Sent: Wednesday, February 15, 2012 1:31 PM >> To: Ravindran, Parthasarathi >> Cc: Justin Uberti; rtcweb@ietf.org; public-webrtc@w3.org >> Subject: Re: [rtcweb] Single offer with multiple answer handling in = JSEP >> [was RE: New JSEP draft posted] >>=20 >>=20 >> I'm a bit lost on use case in SIP context - assuming that the UAC did >> not fork but that a proxy or B2BUA did the forking, it seems like the >> UAC should never receive more than one final response. >>=20 >> In the case of moving from desktop to mobile, it seems like that is >> updating the stream and would use a call flow more like update = examples >> in the draft instead of trying to reuse some old answer. >>=20 >>=20 >> On Feb 14, 2012, at 11:24 , Ravindran, Parthasarathi wrote: >>=20 >>> Justin, >>>=20 >>> Some of the usecases could be >>> 1) The same user of a website signed-in in the multiples = devices >> and acts as answerer, the session establishment request to the = identity >> will alert all the signed-in devices and it is possible that multiple >> devices answer to the session. Here, user may move from one device >> (mobile) to another device (desktop) within the session and wishes to >> continue the session with the last answer. Please note that website = is >> flexible to provide this service. >>> 2) RFC 3261 SIP UA offer/answer handling w.r.t INVITE with SDP = to >> multiple 2xx with SDP handling scenario using JSEP >>> 3) Another SIP usecase could be multiple 18x responses with SDP >> for INVITE with SDP and multiple 2xx responses without SDP but order >> within 18x and 200 are not same. Say 2xx of the second 18x is = received >> as the first 2xx. Here, we need to know how second 18x is handled and >> also, the subsequent 2xx is handled. >>>=20 >>> Of course, it is possible to build more usecases around this area. = As >> we made signaling outside the scope of WebRTC, it is upto JS = application >> to decide the order in which offer/answer happens. I'm not relating >> offer/answer FSM with session establishment state like 18x, 2xx but = I'm >> interested in knowing browser media plane behavior in different state = of >> offer/answer handling by which JS application behaves consistently in >> all browsers. >>>=20 >>> Thanks >>> Partha >>>=20 >>>=20 >>> From: Justin Uberti [mailto:juberti@google.com] >>> Sent: Tuesday, February 14, 2012 11:36 PM >>> To: Ravindran, Parthasarathi >>> Cc: rtcweb@ietf.org; public-webrtc@w3.org >>> Subject: Re: Single offer with multiple answer handling in JSEP [was >> RE: [rtcweb] New JSEP draft posted] >>>=20 >>> Partha, >>>=20 >>> I need more information about the use case to provide an accurate >> response. As mentioned in my earlier mail, are both answers 2xx >> responses? >>>=20 >>> On Tue, Feb 14, 2012 at 12:17 PM, Ravindran, Parthasarathi >> wrote: >>> Hi Justin, >>>=20 >>> In this mail thread, Let us define the behavior of multiple (atleast >> two) answers for the single offer in WebRTC browser. Now, Please let = me >> know your opinion for my below mail. >>>=20 >>> Thanks >>> Partha >>>=20 >>> From: Justin Uberti [mailto:juberti@google.com] >>> Sent: Tuesday, February 14, 2012 9:47 PM >>>=20 >>> To: Ravindran, Parthasarathi >>> Cc: rtcweb@ietf.org; public-webrtc@w3.org >>> Subject: Re: Single offer with multiple answer handling in JSEP [was >> RE: [rtcweb] New JSEP draft posted] >>>=20 >>>=20 >>>=20 >>> On Tue, Feb 14, 2012 at 6:39 AM, Ravindran, Parthasarathi >> wrote: >>> Hi Justin, >>>=20 >>> It will be good to mention in the JSEP draft that multiple answers >> for single offer will not lead to RTP Mixing and WebRTC client acts = as >> RTP Endpoint. >>>=20 >>> Failing the second Answer will be limiting the provision in RFC 3264 >> offer/answer itself as RFC 3264 supports single offer with multiple >> answer. Also, it is better to define the behavior in API rather than >> putting this scenario in the browser implementation specific. In = simple >> scenarios (like alerting with one answer, connect with second = answer), >> replacing the previous ANSWER will be expected behavior. This may not = be >> desired behavior in case two connect responses from different WebRTC >> clients received with different answers but there is no other >> alternative solution possible without mixing. >>>=20 >>> Do you need to support 2 final answers, or would the provisional >> answer support provided via SDP_PRANSWER work for you? >>>=20 >>> IMO, it is better to define it explicitly in JSEP that "latest = ANSWER >> to the offer will replace the existing answer is the expected = behavior >> ". Also, Please mentioned that JS application is responsible for >> discarding (terminating) previous ANSWER notification. Please let = me >> your opinion on this closure. >>>=20 >>> Thanks >>> Partha >>>=20 >>> From: Justin Uberti [mailto:juberti@google.com] >>> Sent: Tuesday, February 14, 2012 7:29 PM >>> To: Ravindran, Parthasarathi >>> Cc: rtcweb@ietf.org; public-webrtc@w3.org >>> Subject: Re: Single offer with multiple answer handling in JSEP [was >> RE: [rtcweb] New JSEP draft posted] >>>=20 >>> Regarding your previous mail, an ANSWER after an ANSWER would either >> fail (if we wanted to simplify), or replace the previous ANSWER >> (essentially the same as if you had done setLocalDescription(OFFER, >> localDescription) followed by setRemoteDescription(ANSWER, answer2). >>>=20 >>> In no case would it mix the descriptions/media from both answers. >>>=20 >>> Other comments inline below. >>>=20 >>> On Tue, Feb 14, 2012 at 1:24 AM, Ravindran, Parthasarathi >> wrote: >>> Hi Justin, >>>=20 >>> Adding to my earlier mail, In case answer2 SDP is updated in = offerer1 >> browser without notifying answerer1, then answer1 will continue to >> transmit RTP which may not be desired behavior. IMO, we need to = define >> this behavior clearly in offerer side. Some of the possible solutions >> are >>>=20 >>> 1) offerer1 has to send atleast RTCP BYE packets towards >> answerer1 while accepting the answerer2 SDP. >>>=20 >>> 2) Throw callback to clear answer1 SDP towards offererJS. >>>=20 >>>=20 >>> The application which called setRemoteDescription twice should have >> the best idea about what is going on, and therefore is responsible = for >> notifying answerer1 that its answer has been discarded, if it makes >> sense to do so. No callback should be needed here. >>>=20 >>>=20 >>> Please let me know your opinion here. >>>=20 >>> Thanks >>> Partha >>>=20 >>> From: Ravindran, Parthasarathi >>> Sent: Tuesday, February 14, 2012 12:07 AM >>> To: 'Justin Uberti'; rtcweb@ietf.org; public-webrtc@w3.org >>> Subject: Single offer with multiple answer handling in JSEP [was RE: >> [rtcweb] New JSEP draft posted] >>>=20 >>> Hi Justin, >>>=20 >>> In the draft, it is not spelled out explicitly what is the expected >> behavior in offerer browser in case multiple answer is received for >> single offer. Offer/answer exchange in offerer is as follows: >>>=20 >>> OffererJS->OffererUA: var offer =3D pc.createOffer(null); >>> OffererJS->OffererUA: pc.setLocalDescription(SDP_OFFER, offer); >>> OffererJS->OffererUA: pc.setRemoteDescription(SDP_ANSWER, answer1); >>> OffererUA->Answerer1UA: >>> OffererJS->OffererUA: pc.setRemoteDescription(SDP_ANSWER, answer2); >>> OffererUA->Answerer?UA: ? >>>=20 >>> My understanding is that "answer2" will update "answer1" in browser >> and starting sending/receiving media towards answer2 media IP and = port. >> Could you please explain the expected behavior in offerer browser >> whether it updates the media stream based on the last answer or mixes >> both answerer. >>>=20 >>> Thanks >>> Partha >>>=20 >>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >> Behalf Of Justin Uberti >>> Sent: Thursday, February 09, 2012 2:27 AM >>> To: rtcweb@ietf.org; public-webrtc@w3.org >>> Subject: [rtcweb] New JSEP draft posted >>>=20 >>> Now available at http://www.ietf.org/id/draft-uberti-rtcweb-jsep- >> 01.txt >>>=20 >>> Includes changes based on implementation feedback, and I believe it >> addresses most of the concerns raised in last week's interim = meetings: >>> - Initial documentation provided for each API call, and what state >> changes it causes >>> - More examples, including a complete basic sample application >>> - Simplified approach to trickle candidate handling >>> - Resolved concerns about how to separate SDP attributes into media = / >> transport >>> - Provided encapsulation for SDP blobs and ICE candidate lines, in = the >> event we want to change encodings or provide helper functions for JS >>> - Provided mechanism for limiting candidates to TURN-only >>> - Resolved several implementation issues >>>=20 >>> I have not yet addressed the non-overlapping codec concern mentioned >> in the interim meeting. I think there are ways of handling this = either >> in the application or the implementation, but I wanted to get this = -01 >> out first for feedback. >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >=20 From pravindran@sonusnet.com Wed Feb 15 23:14: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 E47D021E8017 for ; Wed, 15 Feb 2012 23:14:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 8ho-uy1VmJnl for ; Wed, 15 Feb 2012 23:14:09 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 5A72221F8559 for ; Wed, 15 Feb 2012 23:14:09 -0800 (PST) Received: from sonusmail07.sonusnet.com (sonusmail07.sonusnet.com [10.128.32.157]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q1G7EsAM018546; Thu, 16 Feb 2012 02:14:54 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 16 Feb 2012 02:14:05 -0500 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 16 Feb 2012 12:41:07 +0530 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; Thu, 16 Feb 2012 12:41:06 +0530 From: "Ravindran, Parthasarathi" To: Cullen Jennings , Justin Uberti Thread-Topic: [rtcweb] Single offer with multiple answer handling in JSEP [was RE: New JSEP draft posted] Thread-Index: AQHM67gG55cr02A1XECJjPr/R3Q48ZY9oafAgAF6hIA= Date: Thu, 16 Feb 2012 07:11:05 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E040130@inba-mail01.sonusnet.com> References: <387F9047F55E8C42850AD6B3A7A03C6C0E03F8A4@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E03FAB5@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E03FB7C@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E03FC20@inba-mail01.sonusnet.com> <9ED4A9AC-37C7-4E6D-B6C6-4D3C9537B356@iii.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.70] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 16 Feb 2012 07:11:07.0266 (UTC) FILETIME=[27138E20:01CCEC7A] Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] Single offer with multiple answer handling in JSEP [was RE: New JSEP draft posted] 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, 16 Feb 2012 07:14:14 -0000 Cullen/Justin, Single offer with multiple answer open item is not addressed in -02 version= of JSEP draft. Hope you first agree this as an open item in JSEP. Thanks Partha >-----Original Message----- >From: Ravindran, Parthasarathi >Sent: Wednesday, February 15, 2012 2:43 PM >To: 'Cullen Jennings' >Cc: Justin Uberti; rtcweb@ietf.org; public-webrtc@w3.org >Subject: RE: [rtcweb] Single offer with multiple answer handling in JSEP >[was RE: New JSEP draft posted] > >Cullen, > >RFC3261 references for receiving multiple 2xx in UAC which does not fork >INVITE are as follows: > > >Sec 13.1 Para 3: > >Therefore, when multiple 2xx responses are received from different >remote UAs (because the INVITE forked), each 2xx establishes a different >dialog. All these dialogs are part of the same call. > >Sec 13.2.2.4 2xx Responses > > Multiple 2xx responses may arrive at the UAC for a single INVITE > request due to a forking proxy. Each response is distinguished by > the tag parameter in the To header field, and each represents a > distinct dialog, with a distinct dialog identifier. > > If, after acknowledging any 2xx response to an INVITE, the UAC does > not want to continue with that dialog, then the UAC MUST terminate > the dialog by sending a BYE request as described in Section 15. > > >As per the last statements, it is upto the SIP application to decide >which one of the final 2xx response has to be included within the call. >The usecase 3 is based on RFC3262 (PRACK) support wherein it is possible >to receive multiple forked 18x with SDP followed by 2xx with or without >SDP and SIP 2xx response is not tied to offer/answer exchange. > >I have provided mobile to desktop as an example to justify the last >answer may be used in the offer in some JS application. As I mentioned >below, there is no need to restrict updating latest answer for an offer >in terms of API and protocol. > >Thanks >Partha > >>-----Original Message----- >>From: Cullen Jennings [mailto:fluffy@iii.ca] >>Sent: Wednesday, February 15, 2012 1:31 PM >>To: Ravindran, Parthasarathi >>Cc: Justin Uberti; rtcweb@ietf.org; public-webrtc@w3.org >>Subject: Re: [rtcweb] Single offer with multiple answer handling in >>JSEP [was RE: New JSEP draft posted] >> >> >>I'm a bit lost on use case in SIP context - assuming that the UAC did >>not fork but that a proxy or B2BUA did the forking, it seems like the >>UAC should never receive more than one final response. >> >>In the case of moving from desktop to mobile, it seems like that is >>updating the stream and would use a call flow more like update examples >>in the draft instead of trying to reuse some old answer. >> >> >>On Feb 14, 2012, at 11:24 , Ravindran, Parthasarathi wrote: >> >>> Justin, >>> >>> Some of the usecases could be >>> 1) The same user of a website signed-in in the multiples devices >>and acts as answerer, the session establishment request to the >>identity will alert all the signed-in devices and it is possible that >>multiple devices answer to the session. Here, user may move from one >>device >>(mobile) to another device (desktop) within the session and wishes to >>continue the session with the last answer. Please note that website is >>flexible to provide this service. >>> 2) RFC 3261 SIP UA offer/answer handling w.r.t INVITE with SDP >to >>multiple 2xx with SDP handling scenario using JSEP >>> 3) Another SIP usecase could be multiple 18x responses with SDP >>for INVITE with SDP and multiple 2xx responses without SDP but order >>within 18x and 200 are not same. Say 2xx of the second 18x is received >>as the first 2xx. Here, we need to know how second 18x is handled and >>also, the subsequent 2xx is handled. >>> >>> Of course, it is possible to build more usecases around this area. As >>we made signaling outside the scope of WebRTC, it is upto JS >>application to decide the order in which offer/answer happens. I'm not >>relating offer/answer FSM with session establishment state like 18x, >>2xx but I'm interested in knowing browser media plane behavior in >>different state of offer/answer handling by which JS application >>behaves consistently in all browsers. >>> >>> Thanks >>> Partha >>> >>> >>> From: Justin Uberti [mailto:juberti@google.com] >>> Sent: Tuesday, February 14, 2012 11:36 PM >>> To: Ravindran, Parthasarathi >>> Cc: rtcweb@ietf.org; public-webrtc@w3.org >>> Subject: Re: Single offer with multiple answer handling in JSEP [was >>RE: [rtcweb] New JSEP draft posted] >>> >>> Partha, >>> >>> I need more information about the use case to provide an accurate >>response. As mentioned in my earlier mail, are both answers 2xx >>responses? >>> >>> On Tue, Feb 14, 2012 at 12:17 PM, Ravindran, Parthasarathi >> wrote: >>> Hi Justin, >>> >>> In this mail thread, Let us define the behavior of multiple (atleast >>two) answers for the single offer in WebRTC browser. Now, Please let >>me know your opinion for my below mail. >>> >>> Thanks >>> Partha >>> >>> From: Justin Uberti [mailto:juberti@google.com] >>> Sent: Tuesday, February 14, 2012 9:47 PM >>> >>> To: Ravindran, Parthasarathi >>> Cc: rtcweb@ietf.org; public-webrtc@w3.org >>> Subject: Re: Single offer with multiple answer handling in JSEP [was >>RE: [rtcweb] New JSEP draft posted] >>> >>> >>> >>> On Tue, Feb 14, 2012 at 6:39 AM, Ravindran, Parthasarathi >> wrote: >>> Hi Justin, >>> >>> It will be good to mention in the JSEP draft that multiple answers >>for single offer will not lead to RTP Mixing and WebRTC client acts as >>RTP Endpoint. >>> >>> Failing the second Answer will be limiting the provision in RFC 3264 >>offer/answer itself as RFC 3264 supports single offer with multiple >>answer. Also, it is better to define the behavior in API rather than >>putting this scenario in the browser implementation specific. In simple >>scenarios (like alerting with one answer, connect with second answer), >>replacing the previous ANSWER will be expected behavior. This may not >>be desired behavior in case two connect responses from different WebRTC >>clients received with different answers but there is no other >>alternative solution possible without mixing. >>> >>> Do you need to support 2 final answers, or would the provisional >>answer support provided via SDP_PRANSWER work for you? >>> >>> IMO, it is better to define it explicitly in JSEP that "latest ANSWER >>to the offer will replace the existing answer is the expected behavior >>". Also, Please mentioned that JS application is responsible for >>discarding (terminating) previous ANSWER notification. Please let me >>your opinion on this closure. >>> >>> Thanks >>> Partha >>> >>> From: Justin Uberti [mailto:juberti@google.com] >>> Sent: Tuesday, February 14, 2012 7:29 PM >>> To: Ravindran, Parthasarathi >>> Cc: rtcweb@ietf.org; public-webrtc@w3.org >>> Subject: Re: Single offer with multiple answer handling in JSEP [was >>RE: [rtcweb] New JSEP draft posted] >>> >>> Regarding your previous mail, an ANSWER after an ANSWER would either >>fail (if we wanted to simplify), or replace the previous ANSWER >>(essentially the same as if you had done setLocalDescription(OFFER, >>localDescription) followed by setRemoteDescription(ANSWER, answer2). >>> >>> In no case would it mix the descriptions/media from both answers. >>> >>> Other comments inline below. >>> >>> On Tue, Feb 14, 2012 at 1:24 AM, Ravindran, Parthasarathi >> wrote: >>> Hi Justin, >>> >>> Adding to my earlier mail, In case answer2 SDP is updated in offerer1 >>browser without notifying answerer1, then answer1 will continue to >>transmit RTP which may not be desired behavior. IMO, we need to define >>this behavior clearly in offerer side. Some of the possible solutions >>are >>> >>> 1) offerer1 has to send atleast RTCP BYE packets towards >>answerer1 while accepting the answerer2 SDP. >>> >>> 2) Throw callback to clear answer1 SDP towards offererJS. >>> >>> >>> The application which called setRemoteDescription twice should have >>the best idea about what is going on, and therefore is responsible for >>notifying answerer1 that its answer has been discarded, if it makes >>sense to do so. No callback should be needed here. >>> >>> >>> Please let me know your opinion here. >>> >>> Thanks >>> Partha >>> >>> From: Ravindran, Parthasarathi >>> Sent: Tuesday, February 14, 2012 12:07 AM >>> To: 'Justin Uberti'; rtcweb@ietf.org; public-webrtc@w3.org >>> Subject: Single offer with multiple answer handling in JSEP [was RE: >>[rtcweb] New JSEP draft posted] >>> >>> Hi Justin, >>> >>> In the draft, it is not spelled out explicitly what is the expected >>behavior in offerer browser in case multiple answer is received for >>single offer. Offer/answer exchange in offerer is as follows: >>> >>> OffererJS->OffererUA: var offer =3D pc.createOffer(null); >>> OffererJS->OffererUA: pc.setLocalDescription(SDP_OFFER, offer); >>> OffererJS->OffererUA: pc.setRemoteDescription(SDP_ANSWER, answer1); >>> OffererUA->Answerer1UA: >>> OffererJS->OffererUA: pc.setRemoteDescription(SDP_ANSWER, answer2); >>> OffererUA->Answerer?UA: ? >>> >>> My understanding is that "answer2" will update "answer1" in browser >>and starting sending/receiving media towards answer2 media IP and port. >>Could you please explain the expected behavior in offerer browser >>whether it updates the media stream based on the last answer or mixes >>both answerer. >>> >>> Thanks >>> Partha >>> >>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >>Behalf Of Justin Uberti >>> Sent: Thursday, February 09, 2012 2:27 AM >>> To: rtcweb@ietf.org; public-webrtc@w3.org >>> Subject: [rtcweb] New JSEP draft posted >>> >>> Now available at http://www.ietf.org/id/draft-uberti-rtcweb-jsep- >>01.txt >>> >>> Includes changes based on implementation feedback, and I believe it >>addresses most of the concerns raised in last week's interim meetings: >>> - Initial documentation provided for each API call, and what state >>changes it causes >>> - More examples, including a complete basic sample application >>> - Simplified approach to trickle candidate handling >>> - Resolved concerns about how to separate SDP attributes into media / >>transport >>> - Provided encapsulation for SDP blobs and ICE candidate lines, in >>> the >>event we want to change encodings or provide helper functions for JS >>> - Provided mechanism for limiting candidates to TURN-only >>> - Resolved several implementation issues >>> >>> I have not yet addressed the non-overlapping codec concern mentioned >>in the interim meeting. I think there are ways of handling this either >>in the application or the implementation, but I wanted to get this -01 >>out first for feedback. >>> >>> >>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb From christer.holmberg@ericsson.com Thu Feb 16 00:01: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 0DE0521E8013 for ; Thu, 16 Feb 2012 00:01:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.393 X-Spam-Level: X-Spam-Status: No, score=-9.393 tagged_above=-999 required=5 tests=[AWL=0.606, BAYES_00=-2.599, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPLIS3P0dUwL for ; Thu, 16 Feb 2012 00:01:29 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 2875221E804F for ; Thu, 16 Feb 2012 00:01:28 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-a1-4f3cb7d79322 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 34.DC.27041.7D7BC3F4; Thu, 16 Feb 2012 09:01:27 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Thu, 16 Feb 2012 09:01:27 +0100 From: Christer Holmberg To: Cullen Jennings Date: Thu, 16 Feb 2012 09:01:26 +0100 Thread-Topic: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case Thread-Index: AczsdeTbwrbBTx3nSA223EACYY7b4wACM4Qw Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3D87E58F@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C3D87E060@ESESSCMS0356.eemea.ericsson.se> <3CBDF06F-F52D-4C09-A78F-1A0D8479572A@iii.ca> In-Reply-To: <3CBDF06F-F52D-4C09-A78F-1A0D8479572A@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-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case 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, 16 Feb 2012 08:01:30 -0000 Hi,=20 (I changed the subject to JSEP-02) >> Section 6.1.4 of jsep-01 says: >> =20 >> "SDP_PRANSWER indicates that a description should be parsed as a= n >> answer, but not a final answer, and so should not result in the >> starting of media transmission. A description used as a SDP_PRA= NSWER >> may be applied as a response to a SDP_OFFER, or an update to a >> previously sent SDP_PRANSWER." >> =20 >> =20 >> Section 7.6 shows a SIP early media (FEDEX) use-case, where an SDP answe= r received in a SIP 18x response is provided to the browser as a SDP_PRANSW= ER. >> =20 >> =20 >> Q1: Since SDP_PRANSWER is not supposed to start media transmission, how = will the use-case work? As=20 >> far as I know, media transmission is needed for the FEDEX use-case. > > Consider a browser A that implemented a protocol something like ROAP usin= g the JSEP API so it is=20 > going to a ROAP to SIP GW then then goes to a GW to the PSTN that calls 1= -800 go fedex.=20 > > The browser does a createOffer followed by setLocal with offer and sends = the offer to the ROAP=20 > to SIP GW which turns it into an INVITE with offer to the PSTN GW. At thi= s point the browse is=20 > listening to any media the PSTN GW might send. The PSTN GW sends 180 with= SDP that gets mapped =20 > back to a setRemote with SDP_PRANSWER. That allows the browser and GW to = do ICE, DTLS , etc and=20 > at this point the PSTN GW can start sending media to the browser. Given w= e just need 1 way media=20 > at this point, not sure it matter much if browser sends any media or not.= At the point the SIP 200=20 > happens, that gets mapped to a final answer. If we want unidirectional media, can't the same be achieved e.g. with SDP_A= NSWER and a=3Drecvonly? (Also, in the FEDEX case, there could be scenarios where the browser does n= eed to transit media, if the user is e.g. promted for DTMFs, voice commands= etc...) =20 >> Q2: The draft doesn't really specify what SDP_PRANSWER is used for. I un= derstand that it means=20 >> that a "final" answer may be provided later, but it doesn't really say w= hat the a browser would=20 >> do with an SDP_PRANSWER - especially since it doesn't seem to enable med= ia. > > I think the key thing is when the JS sets new SDP_OFFER in setLocal, it n= eeds to be willing to=20 > receive the old media and the media for the new SDP. A final answers mean= s you not longer need=20 > to to be able to receive the media for the old SDP. A provisional offer d= oes not allow you stop=20 > being able to receive the media for the old SDP.=20 That sounds very strange to me (and it's not described anywhere). In my opi= noin - once an answer has been received, the browser starts using it, toget= her with the associated offer. Also, I don't see the need for your described behavior in the FEDEX case. B= ecause, since the use-case takes place during session establishment, the mo= st likely is no old SDP. So, you could as well use SDP_ANSWER, and when the= call has been answered a new SDP_ANSWER. Regards, Christer From andrew.hutton@siemens-enterprise.com Thu Feb 16 12: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 68EE021E804E for ; Thu, 16 Feb 2012 12:04:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.242 X-Spam-Level: X-Spam-Status: No, score=-2.242 tagged_above=-999 required=5 tests=[AWL=-0.243, BAYES_00=-2.599, J_CHICKENPOX_18=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Se0W4nySRNih for ; Thu, 16 Feb 2012 12:04:10 -0800 (PST) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 142DD21E8022 for ; Thu, 16 Feb 2012 12:04:10 -0800 (PST) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 44DE61EB846A; Thu, 16 Feb 2012 21:04:08 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 16 Feb 2012 21:04:08 +0100 From: "Hutton, Andrew" To: Christer Holmberg , Cullen Jennings Date: Thu, 16 Feb 2012 21:04:04 +0100 Thread-Topic: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case Thread-Index: AczsdeTbwrbBTx3nSA223EACYY7b4wACM4QwABmmuzA= Message-ID: <101C6067BEC68246B0C3F6843BCCC1E31202EDA663@MCHP058A.global-ad.net> References: <7F2072F1E0DE894DA4B517B93C6A05852C3D87E060@ESESSCMS0356.eemea.ericsson.se> <3CBDF06F-F52D-4C09-A78F-1A0D8479572A@iii.ca> <7F2072F1E0DE894DA4B517B93C6A05852C3D87E58F@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3D87E58F@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 Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case 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, 16 Feb 2012 20:04:14 -0000 See below. > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Christer Holmberg > Sent: 16 February 2012 09:01 > To: Cullen Jennings > Cc: rtcweb@ietf.org; public-webrtc@w3.org > Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >=20 >=20 > Hi, >=20 > (I changed the subject to JSEP-02) >=20 > >> Section 6.1.4 of jsep-01 says: > >> > >> "SDP_PRANSWER indicates that a description should be parsed > as an > >> answer, but not a final answer, and so should not result in > the > >> starting of media transmission. A description used as a > SDP_PRANSWER > >> may be applied as a response to a SDP_OFFER, or an update > to a > >> previously sent SDP_PRANSWER." > >> > >> > >> Section 7.6 shows a SIP early media (FEDEX) use-case, where an SDP > answer received in a SIP 18x response is provided to the browser as a > SDP_PRANSWER. > >> > >> > >> Q1: Since SDP_PRANSWER is not supposed to start media transmission, > how will the use-case work? As > >> far as I know, media transmission is needed for the FEDEX use-case. > > > > Consider a browser A that implemented a protocol something like ROAP > using the JSEP API so it is > > going to a ROAP to SIP GW then then goes to a GW to the PSTN that > calls 1-800 go fedex. > > > > The browser does a createOffer followed by setLocal with offer and > sends the offer to the ROAP > > to SIP GW which turns it into an INVITE with offer to the PSTN GW. At > this point the browse is > > listening to any media the PSTN GW might send. The PSTN GW sends 180 > with SDP that gets mapped > > back to a setRemote with SDP_PRANSWER. That allows the browser and GW > to do ICE, DTLS , etc and > > at this point the PSTN GW can start sending media to the browser. > Given we just need 1 way media > > at this point, not sure it matter much if browser sends any media or > not. At the point the SIP 200 > > happens, that gets mapped to a final answer. >=20 > If we want unidirectional media, can't the same be achieved e.g. with > SDP_ANSWER and a=3Drecvonly? >=20 > (Also, in the FEDEX case, there could be scenarios where the browser > does need to transit media, if the user is e.g. promted for DTMFs, > voice commands etc...) >=20 [AndyH] - I agree that media transmission is required at this stage so that= the user can navigate through voice prompts (E.g. via DTMF) I thought this= was the main requirement from the FEDEX use case. >=20 > >> Q2: The draft doesn't really specify what SDP_PRANSWER is used for. > I understand that it means > >> that a "final" answer may be provided later, but it doesn't really > say what the a browser would > >> do with an SDP_PRANSWER - especially since it doesn't seem to enable > media. > > > > I think the key thing is when the JS sets new SDP_OFFER in setLocal, > it needs to be willing to > > receive the old media and the media for the new SDP. A final answers > means you not longer need > > to to be able to receive the media for the old SDP. A provisional > offer does not allow you stop > > being able to receive the media for the old SDP. >=20 > That sounds very strange to me (and it's not described anywhere). In my > opinoin - once an answer has been received, the browser starts using > it, together with the associated offer. >=20 > Also, I don't see the need for your described behavior in the FEDEX > case. Because, since the use-case takes place during session > establishment, the most likely is no old SDP. So, you could as well use > SDP_ANSWER, and when the call has been answered a new SDP_ANSWER. >=20 >=20 > Regards, >=20 > Christer > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From bernard_aboba@hotmail.com Thu Feb 16 17:02: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 3621221E8079 for ; Thu, 16 Feb 2012 17:02:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.78 X-Spam-Level: X-Spam-Status: No, score=-100.78 tagged_above=-999 required=5 tests=[AWL=-0.782, BAYES_50=0.001, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZ9pfmq7fw5w for ; Thu, 16 Feb 2012 17:02:44 -0800 (PST) Received: from blu0-omc3-s12.blu0.hotmail.com (blu0-omc3-s12.blu0.hotmail.com [65.55.116.87]) by ietfa.amsl.com (Postfix) with ESMTP id 3859221F8570 for ; Thu, 16 Feb 2012 17:02:44 -0800 (PST) Received: from BLU152-DS15 ([65.55.116.74]) by blu0-omc3-s12.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 16 Feb 2012 17:02:43 -0800 X-Originating-IP: [131.107.0.69] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: Bernard Aboba To: Date: Thu, 16 Feb 2012 17:02:42 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_022B_01CCECCC.CC58D8C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcztDy8+bauT6vMrTXKPx12qwuMJqA== Content-Language: en-us X-OriginalArrivalTime: 17 Feb 2012 01:02:43.0377 (UTC) FILETIME=[DA8B8210:01CCED0F] Subject: [rtcweb] JSEP: "simple" SDP subset? 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, 17 Feb 2012 01:02:46 -0000 ------=_NextPart_000_022B_01CCECCC.CC58D8C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit While it's true that JSEP is a step forward compared with the previous API, there Is still something that bothers me about using SDP in the API: do we understand what SDP subset will be supported by JSEP implementations? Or are we setting ourselves up for a nasty interoperability problem? When people talk about SDP on this list, they refer to RFC 3264 offer/answer, but typically don't mention all the SDP extension documents that have had inconsistent takeup since then. This is a bit like having a parent show off a baby picture of their child, saying "isn't she cute?" while neglecting to mention that the picture is 30 years old, and that the "baby" is now living in a trailer in North Dakota with their 5th husband, 8 children, and 6 cats. One of the things I like about JSEP is that the SDP produced by createOffer() could conceivably be simpler than what you'd send over the wire, because it's just an expression of capabilities, not necessarily a full-fledged "offer". For example, if we were dealing with a browser that could support RTP, SRTP, AVP and AVPF, createOffer () wouldn't have to express everything in RFC 5939 syntax, even if that is what was eventually sent. All the application needs is a list of capabilities expressed in SDP from which it could compose an offer itself. However, while the SDP produced and consumed by JSEP can be "simpler", things can get complicated in a hurry. For example: a. What if the user purchased a camera supporting layered video? This is not a hypothetical, these cameras are on the market. Do we know what the m lines look like? b. What if the browser can support RTP, SRTP, AVP and AVPF? Does createOffer() just use the most sophisticated profile (e.g. RTP/SAVPF) to keep things simple, letting the application decide what profile to include (e.g. RTP/SAVP if the responder is a legacy device unlikely to understand RTP/SAVPF, or capneg if the responder is likely to understand it)? c. What if the browser supports multiple security schemes (e.g. SRTP/SDES and DTLS/SRTP)? What does the output of createOffer() look like? I am hoping that JSEP will never need to utilize RFC 5939 semantics in the SDP blobs it produces or consumes, but I can understand if it *may* need to utilize SDP extensions not yet standardized (e.g. SRCNAME). ------=_NextPart_000_022B_01CCECCC.CC58D8C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

While = it’s true that JSEP is a step forward compared with the previous = API, there Is still something that bothers me about using SDP in the = API:  do we understand what SDP subset will be supported by JSEP = implementations?  Or are we setting ourselves up for a nasty = interoperability problem?

 

When people = talk about SDP on this list, they refer to RFC 3264 offer/answer, but = typically don’t mention all the SDP extension documents that have = had inconsistent takeup since then.   This is a bit like = having a parent show off a baby picture of their child, saying = “isn’t she cute?” while neglecting to mention that the = picture is 30 years old, and that the “baby” is now living = in a trailer in North Dakota with their 5th husband, 8 = children, and 6 cats.

 

One of the = things I like about JSEP is that the SDP produced by createOffer() could = conceivably be simpler than what you’d send over the wire, because = it’s just an expression of capabilities, not necessarily a = full-fledged “offer”.   For example, if we were = dealing with a browser that could support RTP, SRTP, AVP and AVPF, = createOffer () wouldn’t have to express everything in RFC 5939 = syntax, even if that is what was eventually sent.  All the = application needs is a list of capabilities expressed in SDP from which = it could compose an offer itself. 

 

However, = while the SDP produced and consumed by JSEP can be = “simpler”, things can get complicated in a hurry.  For = example:

 

a.       = What if the user purchased a camera supporting = layered video?  This is not a hypothetical, these cameras are on = the market.  Do we know what the m lines look = like?

b.      = What if the browser can support RTP, SRTP, AVP = and AVPF?  Does createOffer() just use the most sophisticated = profile (e.g. RTP/SAVPF) to keep things simple, letting the application = decide what profile to include (e.g. RTP/SAVP if the responder is a = legacy device unlikely to understand RTP/SAVPF, or capneg if the = responder is likely to understand it)?

c.       = What if the browser supports multiple security = schemes (e.g. SRTP/SDES and DTLS/SRTP)?  What does the output of = createOffer() look like?

 

I am = hoping that JSEP will never need to utilize RFC 5939 = semantics in the SDP blobs it produces or consumes, but I can understand = if it *may* need to utilize SDP extensions not yet standardized = (e.g. SRCNAME).

 

------=_NextPart_000_022B_01CCECCC.CC58D8C0-- From juberti@google.com Thu Feb 16 18:17: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 6A44521E80B9 for ; Thu, 16 Feb 2012 18:17:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.735 X-Spam-Level: X-Spam-Status: No, score=-102.735 tagged_above=-999 required=5 tests=[AWL=0.241, 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 yi3glN29yu8R for ; Thu, 16 Feb 2012 18:17:29 -0800 (PST) Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF1621E809B for ; Thu, 16 Feb 2012 18:17:28 -0800 (PST) Received: by qan41 with SMTP id 41so3111732qan.10 for ; Thu, 16 Feb 2012 18:17:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=2PwfB7DXWpi5PUY4IqulrfXj8FCI8XITzVtWwBSKOTg=; b=aYRTc/NAFQdbQjow0AkbCQ4uj7Q8eLfoSIgZ6XziVEwP4jpH5LS/nkaRUMkbkhcrLD yEZKnIK+K+6OKEHRXTpz18Ny2BGU7I42ndrp+Nf1gFi8WA9+YT1aciB/yJBhOTA0qBJP ScYjc1gAkHfmiR84w56jXH/Lwemg7M16YQLJw= Received: by 10.229.75.149 with SMTP id y21mr3531265qcj.6.1329445048531; Thu, 16 Feb 2012 18:17:28 -0800 (PST) Received: by 10.229.75.149 with SMTP id y21mr3531253qcj.6.1329445048363; Thu, 16 Feb 2012 18:17:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.29.195 with HTTP; Thu, 16 Feb 2012 18:17:07 -0800 (PST) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3D87E060@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C3D87E060@ESESSCMS0356.eemea.ericsson.se> From: Justin Uberti Date: Thu, 16 Feb 2012 21:17:07 -0500 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=002354470b8cdb2b0404b91f8bce X-System-Of-Record: true X-Gm-Message-State: ALoCoQm01fmhuydqmlWrlCbJ5EYhDnIk2AHTDHRKDJgNZOrqKrjtpJxtJ8Qq/Yeox7cm5WCuWZfbr4pi/AkPecGHLDXwHe01Ci/AD1Y/v3agrhGCl25v5DX6WKUFiMggCfUCG8orCFo/hMrhzXnfe6sOg5azhj6I/A== Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] JSEP-01: SDP_PRANSWER and FEDEX use-case 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, 17 Feb 2012 02:17:34 -0000 --002354470b8cdb2b0404b91f8bce Content-Type: text/plain; charset=UTF-8 On Wed, Feb 15, 2012 at 5:47 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > > Hi, > > Section 6.1.4 of jsep-01 says: > > "SDP_PRANSWER indicates that a description should be parsed as an > answer, but not a final answer, and so should not result in the > starting of media transmission. A description used as a > SDP_PRANSWER > may be applied as a response to a SDP_OFFER, or an update to a > previously sent SDP_PRANSWER." > > > Section 7.6 shows a SIP early media (FEDEX) use-case, where an SDP answer > received in a SIP 18x response is provided to the browser as a SDP_PRANSWER. > > > Q1: Since SDP_PRANSWER is not supposed to start media transmission, how > will the use-case work? As far as I know, media transmission is needed for > the FEDEX use-case. > I think this is just me being unclear. When I say "start media transmission", I mean that when the browser gets a SDP_PRANSWER in response to an offer, the browser will not start transmitting media. However, it will play out any media that is received after the offer is installed, and the gateway can start sending media at any time after it gets the offer. > > Q2: The draft doesn't really specify what SDP_PRANSWER is used for. I > understand that it means that a "final" answer may be provided later, but > it doesn't really say what the a browser would do with an SDP_PRANSWER - > especially since it doesn't seem to enable media. > SDP_PRANSWER allows, among other things, the callee's ICE and SRTP info to be provided so that early media can be received by the caller. I think it should make more sense given my answer to #1. > Q3: Assuming we would allow multiple SDP_ANSWER (see separate thread), is > there a need for SDP_PRANSWER? > SDP_PRANSWER has slightly different semantics in that it is not intended to indicate consent by the callee, whereas SDP_ANSWER does. I still need to review the other thread; there may be other ways of handling this, but this seemed like the simplest to me. > > Regards, > > Christer > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --002354470b8cdb2b0404b91f8bce Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Feb 15, 2012 at 5:47 AM, Christe= r Holmberg <christer.holmberg@ericsson.com> wrote:
=C2=A0
Hi,
=C2=A0
Section 6.1.4 of jsep-01 says:
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "SDP_PRANSWER in= dicates that a description should be parsed as an
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 answer, but not= a final answer, and so should not result in the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 starting of med= ia transmission. A description used as a SDP_PRANSWER
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 may be applied = as a response to a SDP_OFFER, or an update to a
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 previously sent= SDP_PRANSWER."
=C2=A0
=C2=A0
Section 7.6 shows a SIP early media (FEDEX) use-case, where an S= DP answer received in a SIP 18x response is provided to the browser as a SD= P_PRANSWER.
=C2=A0
=C2=A0
Q1: Since SDP_PRANSWER is not supposed to start media transmissi= on, how will the use-case work? As far as I know, media transmission is nee= ded for the FEDEX use-case.

I think this is just me being unclear. When I say "star= t media transmission", I mean that when the browser gets a SDP_PRANSWE= R in response to an offer, the browser will not start transmitting media. H= owever, it will play out any media that is received after the offer is inst= alled, and the gateway can start sending media at any time after it gets th= e offer.
=C2=A0
Q2: The draft doesn't really specify what SDP_PRANSWER is us= ed for. I understand that it means that a "final" answer may be p= rovided later, but it doesn't really say what the a browser would do wi= th an SDP_PRANSWER - especially since it doesn't seem to enable media.


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

SDP_PRANSWER allows, among other things, the callee's = ICE and SRTP info to be provided so that early media can be received by the= caller.=C2=A0I think it should make more sense given my answer to #1.

=C2=A0
Q3: Assuming we would allow multiple SDP_ANSWER (see separate th= read), is there a need for SDP_PRANSWER?

SDP_PRANSWER has slightly different semantics in th= at it is not intended to indicate consent by the callee, whereas SDP_ANSWER= does.=C2=A0

I still need to review the other thread; there may be o= ther ways of handling this, but this seemed like the simplest to me.=C2=A0<= /div>
=C2=A0
Regards,
=C2=A0
Christer
=C2=A0
=C2=A0

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


--002354470b8cdb2b0404b91f8bce-- From juberti@google.com Thu Feb 16 18:24: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 55BC621F863D for ; Thu, 16 Feb 2012 18:24:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.441 X-Spam-Level: X-Spam-Status: No, score=-102.441 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UggZIweIy7uo for ; Thu, 16 Feb 2012 18:24:05 -0800 (PST) Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 37ADE21F863B for ; Thu, 16 Feb 2012 18:24:01 -0800 (PST) Received: by qan41 with SMTP id 41so3116248qan.10 for ; Thu, 16 Feb 2012 18:24:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=iE+TV+oNmBQ4J+U1jGb9oR0GV2+tcjUEke58vlHVm+c=; b=K2t4A/5g7WGihZZiWfZqcB+CiFb37dGwLR8rmp90Arn5wg5WwIVaNBtQvw4GCwPkwJ DG9skm7R9sAea4wFKNlYd326tP5i7CJi5aG9DCpRkjF2M9O7ys3Dgy1r7fASOyfrBDmO 5a5dWmG8W80u9jewcaTTCW6Boodm6WikniCYc= Received: by 10.229.78.203 with SMTP id m11mr3539647qck.86.1329445440446; Thu, 16 Feb 2012 18:24:00 -0800 (PST) Received: by 10.229.78.203 with SMTP id m11mr3539636qck.86.1329445440278; Thu, 16 Feb 2012 18:24:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.29.195 with HTTP; Thu, 16 Feb 2012 18:23:40 -0800 (PST) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3D87E075@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C3D87E075@ESESSCMS0356.eemea.ericsson.se> From: Justin Uberti Date: Thu, 16 Feb 2012 21:23:40 -0500 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=00235429e04037506004b91fa393 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlDgG308hl/UxVvUL5MXF8Yq4k4YUru8wd1foIhMUb921Bzz14XWp1n2ZaIR+0dxNWjqyc9ZIdV6ggo4rXsJZhsCimDYLdzLbmHx8LnkgEi19vgM45FOYxyDo3AvF1c0X+Bjzw9KJQsZLkLfFQBHonYKtyLaA== Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] JSEP-01: Associating ICE candidates with m- lines 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, 17 Feb 2012 02:24:09 -0000 --00235429e04037506004b91fa393 Content-Type: text/plain; charset=UTF-8 On Wed, Feb 15, 2012 at 5:56 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > > Hi, > > In jsep-01, an "m- line reference" has been added to the a=candidate > attribute, in order for the browser to indicate for which m- line the > attribute belongs to. > > Q1: As, within a session, as new SDP offers may be sent (and, as least in > theory I assume, new local candidates may be provided), I wonder whether > it, in addition to the m- line reference, also would be useful to include > an SDP version reference (found the SDP o- line)? > Need to think through the exact scenario where this would come into play, but it seems useful. If you have a flow in mind, I'd be interested in seeing it. > > Q2: If BUNDLE is used, multiple m- lines may share the same candidates, so > it should be possible to indicate that an a=candidate attribute belongs to > multiple m- lines - AND/OR to indicate that it belongs to a given bundle > group. > In this case I was going to have the IceCallback fire twice with the same candidate, once for each m= line. I think this is the simplest approach, but let me know if you see an issue with it. > > Regards, > > Christer > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --00235429e04037506004b91fa393 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Feb 15, 2012 at 5:56 AM, Christe= r Holmberg <christer.holmberg@ericsson.com> wrote:
=C2=A0
Hi,
=C2=A0
In jsep-01, an "m- line reference" has been added to t= he a=3Dcandidate attribute, in order for the browser to indicate for which = m- line the attribute belongs to.
=C2=A0
Q1: As, within a session, as new SDP offers may be sent (and, as= least in theory I assume, new local candidates may be provided), I wonder = whether it, in addition to the m- line reference, also would be useful to i= nclude an SDP version reference (found the SDP o- line)?

Need to think through the exact scenario where this would come into= play, but it seems useful. If you have a flow in mind, I'd be interest= ed in seeing it.
=C2=A0
Q2: If BUNDLE is used, multiple m- lines may share the same cand= idates, so it should be possible to indicate that an a=3Dcandidate attribut= e belongs to multiple m- lines - AND/OR to indicate that it belongs to a gi= ven bundle group.

In this case I was going to h= ave the IceCallback fire twice with the same candidate, once for each m=3D = line. I think this is the simplest approach, but let me know if you see an = issue with it.=C2=A0
=C2=A0
Regards,
=C2=A0
Christer
=C2=A0

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


--00235429e04037506004b91fa393-- From juberti@google.com Thu Feb 16 18:36: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 A3EEF21E804B for ; Thu, 16 Feb 2012 18:36:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.74 X-Spam-Level: X-Spam-Status: No, score=-102.74 tagged_above=-999 required=5 tests=[AWL=0.236, 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 H5k6jsBf39rU for ; Thu, 16 Feb 2012 18:36:14 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5EBB921E8022 for ; Thu, 16 Feb 2012 18:36:05 -0800 (PST) Received: by qafi29 with SMTP id i29so344933qaf.10 for ; Thu, 16 Feb 2012 18:36:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=CSCe4P307gCfr+cU4sT9OELhyecNN8rim0E7W84pO0k=; b=BztWVDunh2dM0k8dub194Ko6k4NbEfAYCWfdhHPZ0p0rpfC6g36x/NKkvej43FR0fQ LYIsARgJa5LwMCgV9//bdyJfh7FyJPtxkvI1azFsqWOMEuC2lVtzCIqoVvr0NTB5rZnf xAHKxM1LkQHe4baq8Xee4c6Ih9L+JEGnPhME8= Received: by 10.229.78.89 with SMTP id j25mr3605830qck.46.1329446164817; Thu, 16 Feb 2012 18:36:04 -0800 (PST) Received: by 10.229.78.89 with SMTP id j25mr3605810qck.46.1329446164623; Thu, 16 Feb 2012 18:36:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.29.195 with HTTP; Thu, 16 Feb 2012 18:35:44 -0800 (PST) In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E040130@inba-mail01.sonusnet.com> References: <387F9047F55E8C42850AD6B3A7A03C6C0E03F8A4@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E03FAB5@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E03FB7C@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E03FC20@inba-mail01.sonusnet.com> <9ED4A9AC-37C7-4E6D-B6C6-4D3C9537B356@iii.ca> <387F9047F55E8C42850AD6B3A7A03C6C0E040130@inba-mail01.sonusnet.com> From: Justin Uberti Date: Thu, 16 Feb 2012 21:35:44 -0500 Message-ID: To: "Ravindran, Parthasarathi" Content-Type: multipart/alternative; boundary=00235429d37463f4aa04b91fce82 X-System-Of-Record: true X-Gm-Message-State: ALoCoQljbcm1fosiNuGf5HlZStoI22rAszaKzmNaslGdb5gX3tGy1AKxm9dnXCmmlzfhSG9wJ70P70hAnHMJhpivgp/T0VK06cO0d1sWATitoe1BJuphSjSasXWyNYclMxjs7OVU8x3ieX9Ez49r9eWcU8eHDm0cFg== Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] Single offer with multiple answer handling in JSEP [was RE: New JSEP draft posted] 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, 17 Feb 2012 02:36:18 -0000 --00235429d37463f4aa04b91fce82 Content-Type: text/plain; charset=UTF-8 Agree it has not been addressed. I'm having some trouble understanding the exact flows that we need to address here (multiple 2xx, multiple 18x followed by 2xx, multiple 18x followed by multiple 2xx) but if I understand correctly your suggestion was: 1) allow a setRemoteDesc(SDP_ANSWER) to follow a setRemoteDesc(SDP_ANSWER) 2) document that in this case (multiple 2xx), the JS is responsible for sending BYE to the previous answerer. which sounds totally reasonable to me. If this sounds good to you, would you mind sketching out a call flow that I could include in the examples section? On Thu, Feb 16, 2012 at 2:11 AM, Ravindran, Parthasarathi < pravindran@sonusnet.com> wrote: > Cullen/Justin, > > Single offer with multiple answer open item is not addressed in -02 > version of JSEP draft. Hope you first agree this as an open item in JSEP. > > Thanks > Partha > > >-----Original Message----- > >From: Ravindran, Parthasarathi > >Sent: Wednesday, February 15, 2012 2:43 PM > >To: 'Cullen Jennings' > >Cc: Justin Uberti; rtcweb@ietf.org; public-webrtc@w3.org > >Subject: RE: [rtcweb] Single offer with multiple answer handling in JSEP > >[was RE: New JSEP draft posted] > > > >Cullen, > > > >RFC3261 references for receiving multiple 2xx in UAC which does not fork > >INVITE are as follows: > > > > > >Sec 13.1 Para 3: > > > >Therefore, when multiple 2xx responses are received from different > >remote UAs (because the INVITE forked), each 2xx establishes a different > >dialog. All these dialogs are part of the same call. > > > >Sec 13.2.2.4 2xx Responses > > > > Multiple 2xx responses may arrive at the UAC for a single INVITE > > request due to a forking proxy. Each response is distinguished by > > the tag parameter in the To header field, and each represents a > > distinct dialog, with a distinct dialog identifier. > > > > If, after acknowledging any 2xx response to an INVITE, the UAC does > > not want to continue with that dialog, then the UAC MUST terminate > > the dialog by sending a BYE request as described in Section 15. > > > > > >As per the last statements, it is upto the SIP application to decide > >which one of the final 2xx response has to be included within the call. > >The usecase 3 is based on RFC3262 (PRACK) support wherein it is possible > >to receive multiple forked 18x with SDP followed by 2xx with or without > >SDP and SIP 2xx response is not tied to offer/answer exchange. > > > >I have provided mobile to desktop as an example to justify the last > >answer may be used in the offer in some JS application. As I mentioned > >below, there is no need to restrict updating latest answer for an offer > >in terms of API and protocol. > > > >Thanks > >Partha > > > >>-----Original Message----- > >>From: Cullen Jennings [mailto:fluffy@iii.ca] > >>Sent: Wednesday, February 15, 2012 1:31 PM > >>To: Ravindran, Parthasarathi > >>Cc: Justin Uberti; rtcweb@ietf.org; public-webrtc@w3.org > >>Subject: Re: [rtcweb] Single offer with multiple answer handling in > >>JSEP [was RE: New JSEP draft posted] > >> > >> > >>I'm a bit lost on use case in SIP context - assuming that the UAC did > >>not fork but that a proxy or B2BUA did the forking, it seems like the > >>UAC should never receive more than one final response. > >> > >>In the case of moving from desktop to mobile, it seems like that is > >>updating the stream and would use a call flow more like update examples > >>in the draft instead of trying to reuse some old answer. > >> > >> > >>On Feb 14, 2012, at 11:24 , Ravindran, Parthasarathi wrote: > >> > >>> Justin, > >>> > >>> Some of the usecases could be > >>> 1) The same user of a website signed-in in the multiples devices > >>and acts as answerer, the session establishment request to the > >>identity will alert all the signed-in devices and it is possible that > >>multiple devices answer to the session. Here, user may move from one > >>device > >>(mobile) to another device (desktop) within the session and wishes to > >>continue the session with the last answer. Please note that website is > >>flexible to provide this service. > >>> 2) RFC 3261 SIP UA offer/answer handling w.r.t INVITE with SDP > >to > >>multiple 2xx with SDP handling scenario using JSEP > >>> 3) Another SIP usecase could be multiple 18x responses with SDP > >>for INVITE with SDP and multiple 2xx responses without SDP but order > >>within 18x and 200 are not same. Say 2xx of the second 18x is received > >>as the first 2xx. Here, we need to know how second 18x is handled and > >>also, the subsequent 2xx is handled. > >>> > >>> Of course, it is possible to build more usecases around this area. As > >>we made signaling outside the scope of WebRTC, it is upto JS > >>application to decide the order in which offer/answer happens. I'm not > >>relating offer/answer FSM with session establishment state like 18x, > >>2xx but I'm interested in knowing browser media plane behavior in > >>different state of offer/answer handling by which JS application > >>behaves consistently in all browsers. > >>> > >>> Thanks > >>> Partha > >>> > >>> > >>> From: Justin Uberti [mailto:juberti@google.com] > >>> Sent: Tuesday, February 14, 2012 11:36 PM > >>> To: Ravindran, Parthasarathi > >>> Cc: rtcweb@ietf.org; public-webrtc@w3.org > >>> Subject: Re: Single offer with multiple answer handling in JSEP [was > >>RE: [rtcweb] New JSEP draft posted] > >>> > >>> Partha, > >>> > >>> I need more information about the use case to provide an accurate > >>response. As mentioned in my earlier mail, are both answers 2xx > >>responses? > >>> > >>> On Tue, Feb 14, 2012 at 12:17 PM, Ravindran, Parthasarathi > >> wrote: > >>> Hi Justin, > >>> > >>> In this mail thread, Let us define the behavior of multiple (atleast > >>two) answers for the single offer in WebRTC browser. Now, Please let > >>me know your opinion for my below mail. > >>> > >>> Thanks > >>> Partha > >>> > >>> From: Justin Uberti [mailto:juberti@google.com] > >>> Sent: Tuesday, February 14, 2012 9:47 PM > >>> > >>> To: Ravindran, Parthasarathi > >>> Cc: rtcweb@ietf.org; public-webrtc@w3.org > >>> Subject: Re: Single offer with multiple answer handling in JSEP [was > >>RE: [rtcweb] New JSEP draft posted] > >>> > >>> > >>> > >>> On Tue, Feb 14, 2012 at 6:39 AM, Ravindran, Parthasarathi > >> wrote: > >>> Hi Justin, > >>> > >>> It will be good to mention in the JSEP draft that multiple answers > >>for single offer will not lead to RTP Mixing and WebRTC client acts as > >>RTP Endpoint. > >>> > >>> Failing the second Answer will be limiting the provision in RFC 3264 > >>offer/answer itself as RFC 3264 supports single offer with multiple > >>answer. Also, it is better to define the behavior in API rather than > >>putting this scenario in the browser implementation specific. In simple > >>scenarios (like alerting with one answer, connect with second answer), > >>replacing the previous ANSWER will be expected behavior. This may not > >>be desired behavior in case two connect responses from different WebRTC > >>clients received with different answers but there is no other > >>alternative solution possible without mixing. > >>> > >>> Do you need to support 2 final answers, or would the provisional > >>answer support provided via SDP_PRANSWER work for you? > >>> > >>> IMO, it is better to define it explicitly in JSEP that "latest ANSWER > >>to the offer will replace the existing answer is the expected behavior > >>". Also, Please mentioned that JS application is responsible for > >>discarding (terminating) previous ANSWER notification. Please let me > >>your opinion on this closure. > >>> > >>> Thanks > >>> Partha > >>> > >>> From: Justin Uberti [mailto:juberti@google.com] > >>> Sent: Tuesday, February 14, 2012 7:29 PM > >>> To: Ravindran, Parthasarathi > >>> Cc: rtcweb@ietf.org; public-webrtc@w3.org > >>> Subject: Re: Single offer with multiple answer handling in JSEP [was > >>RE: [rtcweb] New JSEP draft posted] > >>> > >>> Regarding your previous mail, an ANSWER after an ANSWER would either > >>fail (if we wanted to simplify), or replace the previous ANSWER > >>(essentially the same as if you had done setLocalDescription(OFFER, > >>localDescription) followed by setRemoteDescription(ANSWER, answer2). > >>> > >>> In no case would it mix the descriptions/media from both answers. > >>> > >>> Other comments inline below. > >>> > >>> On Tue, Feb 14, 2012 at 1:24 AM, Ravindran, Parthasarathi > >> wrote: > >>> Hi Justin, > >>> > >>> Adding to my earlier mail, In case answer2 SDP is updated in offerer1 > >>browser without notifying answerer1, then answer1 will continue to > >>transmit RTP which may not be desired behavior. IMO, we need to define > >>this behavior clearly in offerer side. Some of the possible solutions > >>are > >>> > >>> 1) offerer1 has to send atleast RTCP BYE packets towards > >>answerer1 while accepting the answerer2 SDP. > >>> > >>> 2) Throw callback to clear answer1 SDP towards offererJS. > >>> > >>> > >>> The application which called setRemoteDescription twice should have > >>the best idea about what is going on, and therefore is responsible for > >>notifying answerer1 that its answer has been discarded, if it makes > >>sense to do so. No callback should be needed here. > >>> > >>> > >>> Please let me know your opinion here. > >>> > >>> Thanks > >>> Partha > >>> > >>> From: Ravindran, Parthasarathi > >>> Sent: Tuesday, February 14, 2012 12:07 AM > >>> To: 'Justin Uberti'; rtcweb@ietf.org; public-webrtc@w3.org > >>> Subject: Single offer with multiple answer handling in JSEP [was RE: > >>[rtcweb] New JSEP draft posted] > >>> > >>> Hi Justin, > >>> > >>> In the draft, it is not spelled out explicitly what is the expected > >>behavior in offerer browser in case multiple answer is received for > >>single offer. Offer/answer exchange in offerer is as follows: > >>> > >>> OffererJS->OffererUA: var offer = pc.createOffer(null); > >>> OffererJS->OffererUA: pc.setLocalDescription(SDP_OFFER, offer); > >>> OffererJS->OffererUA: pc.setRemoteDescription(SDP_ANSWER, answer1); > >>> OffererUA->Answerer1UA: > >>> OffererJS->OffererUA: pc.setRemoteDescription(SDP_ANSWER, answer2); > >>> OffererUA->Answerer?UA: ? > >>> > >>> My understanding is that "answer2" will update "answer1" in browser > >>and starting sending/receiving media towards answer2 media IP and port. > >>Could you please explain the expected behavior in offerer browser > >>whether it updates the media stream based on the last answer or mixes > >>both answerer. > >>> > >>> Thanks > >>> Partha > >>> > >>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > >>Behalf Of Justin Uberti > >>> Sent: Thursday, February 09, 2012 2:27 AM > >>> To: rtcweb@ietf.org; public-webrtc@w3.org > >>> Subject: [rtcweb] New JSEP draft posted > >>> > >>> Now available at http://www.ietf.org/id/draft-uberti-rtcweb-jsep- > >>01.txt > >>> > >>> Includes changes based on implementation feedback, and I believe it > >>addresses most of the concerns raised in last week's interim meetings: > >>> - Initial documentation provided for each API call, and what state > >>changes it causes > >>> - More examples, including a complete basic sample application > >>> - Simplified approach to trickle candidate handling > >>> - Resolved concerns about how to separate SDP attributes into media / > >>transport > >>> - Provided encapsulation for SDP blobs and ICE candidate lines, in > >>> the > >>event we want to change encodings or provide helper functions for JS > >>> - Provided mechanism for limiting candidates to TURN-only > >>> - Resolved several implementation issues > >>> > >>> I have not yet addressed the non-overlapping codec concern mentioned > >>in the interim meeting. I think there are ways of handling this either > >>in the application or the implementation, but I wanted to get this -01 > >>out first for feedback. > >>> > >>> > >>> > >>> _______________________________________________ > >>> rtcweb mailing list > >>> rtcweb@ietf.org > >>> https://www.ietf.org/mailman/listinfo/rtcweb > > --00235429d37463f4aa04b91fce82 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Agree it has not been addressed. I'm having some trouble understanding = the exact flows that we need to address here (multiple 2xx, multiple 18x fo= llowed by 2xx, multiple 18x followed by multiple 2xx) but if I understand c= orrectly your suggestion was:

1) allow a setRemoteDesc(SDP_ANSWER) to follow a setRemoteDe= sc(SDP_ANSWER)
2) document that in this case (multiple 2xx), the = JS is responsible for sending BYE to the previous answerer.

which sounds totally reasonable to me.=C2=A0

If this sounds good to you, would you mind sketching out a call flow = that I could include in the examples section?

On Thu, Feb 16, 2012 at 2:11 AM, R= avindran, Parthasarathi <pravindran@sonusnet.com> wrote:
Cullen/Justin,

Single offer with multiple answer open item is not addressed in -02 version= of JSEP draft. Hope you first agree this as an open item in JSEP.

Thanks
Partha

>-----Original Message-----
>From: Ravindran, Parthasarathi
>Sent: Wednesday, February 15, 2012 2:43 PM
>To: 'Cullen Jennings'
>Cc: Justin Uberti; rtcweb@ietf.org; public-webrtc@w3.org
>Subject: RE: [rtcweb] Single offer with multiple answer handling in JSE= P
>[was RE: New JSEP draft posted]
>
>Cullen,
>
>RFC3261 references for receiving multiple 2xx in UAC which does not for= k
>INVITE are as follows:
>
><RFC quote>
>Sec 13.1 Para 3:
>
>Therefore, when multiple 2xx responses are received from different
>remote UAs (because the INVITE forked), each 2xx establishes a differen= t
>dialog. =C2=A0All these dialogs are part of the same call.
>
>Sec 13.2.2.4 2xx Responses
>
> =C2=A0 Multiple 2xx responses may arrive at the UAC for a single INVIT= E
> =C2=A0 request due to a forking proxy. =C2=A0Each response is distingu= ished by
> =C2=A0 the tag parameter in the To header field, and each represents a=
> =C2=A0 distinct dialog, with a distinct dialog identifier.
>
> =C2=A0 If, after acknowledging any 2xx response to an INVITE, the UAC = does
> =C2=A0 not want to continue with that dialog, then the UAC MUST termin= ate
> =C2=A0 the dialog by sending a BYE request as described in Section 15.=
></RFC quote>
>
>As per the last statements, it is upto the SIP application to decide >which one of the final 2xx response has to be included within the call.=
>The usecase 3 is based on RFC3262 (PRACK) support wherein it is possibl= e
>to receive multiple forked 18x with SDP followed by 2xx with or without=
>SDP and SIP 2xx response is not tied to offer/answer exchange.
>
>I have provided mobile to desktop as an example to justify the last
>answer may be used in the offer in some JS application. As I mentioned<= br> >below, there is no need to restrict updating latest answer for an offer=
>in terms of API and protocol.
>
>Thanks
>Partha
>
>>-----Original Message-----
>>From: Cullen Jennings [mailto:fluf= fy@iii.ca]
>>Sent: Wednesday, February 15, = 2012 1:31 PM
>>To: Ravindran, Parthasarathi
>>Cc: Justin Uberti; rtcweb@ietf.org; public-webrtc@w3.org
>>Subject: Re: [rtcweb] Single offer with multiple answer handling in=
>>JSEP [was RE: New JSEP draft posted]
>>
>>
>>I'm a bit lost on use case in SIP context - assuming that the U= AC did
>>not fork but that a proxy or B2BUA did the forking, it seems like t= he
>>UAC should never receive more than one final response.
>>
>>In the case of moving from desktop to mobile, it seems like that is=
>>updating the stream and would use a call flow more like update exam= ples
>>in the draft instead of trying to reuse some old answer.
>>
>>
>>On Feb 14, 2012, at 11:24 , Ravindran, Parthasarathi wrote:
>>
>>> Justin,
>>>
>>> Some of the usecases could be
>>> 1) =C2=A0 =C2=A0 =C2=A0The same user of a website signed-in in= the multiples devices
>>and acts as answerer, =C2=A0the session establishment request to th= e
>>identity will alert all the signed-in devices and it is possible th= at
>>multiple devices answer to the session. Here, user may move from on= e
>>device
>>(mobile) to another device (desktop) within the session and wishes = to
>>continue the session with the last answer. Please note that website= is
>>flexible to provide this service.
>>> 2) =C2=A0 =C2=A0 =C2=A0RFC 3261 SIP UA offer/answer handling w= .r.t INVITE with SDP
>to
>>multiple 2xx with SDP handling scenario using JSEP
>>> 3) =C2=A0 =C2=A0 =C2=A0Another SIP usecase could be multiple 1= 8x responses with SDP
>>for INVITE with SDP and multiple 2xx responses without SDP but orde= r
>>within 18x and 200 are not same. Say 2xx of the second 18x is recei= ved
>>as the first 2xx. Here, we need to know how second 18x is handled a= nd
>>also, the subsequent 2xx is handled.
>>>
>>> Of course, it is possible to build more usecases around this a= rea. As
>>we made signaling outside the scope of WebRTC, it is upto JS
>>application to decide the order in which offer/answer happens. I= 9;m not
>>relating offer/answer FSM with session establishment state like 18x= ,
>>2xx but I'm interested in knowing browser media plane behavior = in
>>different state of offer/answer handling by which JS application >>behaves consistently in all browsers.
>>>
>>> Thanks
>>> Partha
>>>
>>>
>>> From: Justin Uberti [mailto:juberti@google.com]
>>> Sent: Tuesday, February 14, 2012 11:36 PM
>>> To: Ravindran, Parthasarathi
>>> Cc: rtcweb@ietf.org; public-webrtc@w3.org
>>> Subject: Re: Single offer with multiple answer handling in JSE= P [was
>>RE: [rtcweb] New JSEP draft posted]
>>>
>>> Partha,
>>>
>>> I need more information about the use case to provide an accur= ate
>>response. As mentioned in my earlier mail, are both answers 2xx
>>responses?
>>>
>>> On Tue, Feb 14, 2012 at 12:17 PM, Ravindran, Parthasarathi
>><pravindran@sonusnet.= com> wrote:
>>> Hi Justin,
>>>
>>> In this mail thread, Let us define the behavior of multiple (a= tleast
>>two) answers for the single offer in WebRTC browser. =C2=A0Now, Ple= ase let
>>me know your opinion for my below mail.
>>>
>>> Thanks
>>> Partha
>>>
>>> From: Justin Uberti [mailto:juberti@google.com]
>>> Sent: Tuesday, February 14, 2012 9:47 PM
>>>
>>> To: Ravindran, Parthasarathi
>>> Cc: rtcweb@ietf.org; public-webrtc@w3.org
>>> Subject: Re: Single offer with multiple answer handling in JSE= P [was
>>RE: [rtcweb] New JSEP draft posted]
>>>
>>>
>>>
>>> On Tue, Feb 14, 2012 at 6:39 AM, Ravindran, Parthasarathi
>><pravindran@sonusnet.= com> wrote:
>>> Hi Justin,
>>>
>>> It will be good to mention in the JSEP draft =C2=A0that multip= le answers
>>for single offer will not lead to RTP Mixing and WebRTC client acts= as
>>RTP Endpoint.
>>>
>>> Failing the second Answer will be limiting the provision in RF= C 3264
>>offer/answer itself as RFC 3264 supports single offer with multiple=
>>answer. Also, it is better to define the behavior in API rather tha= n
>>putting this scenario in the browser implementation specific. In si= mple
>>scenarios (like alerting with one answer, connect with second answe= r),
>>replacing the previous ANSWER will be expected behavior. This may n= ot
>>be desired behavior in case two connect responses from different We= bRTC
>>clients received with different answers =C2=A0but there is no other=
>>alternative solution possible without mixing.
>>>
>>> Do you need to support 2 final answers, or would the provision= al
>>answer support provided via SDP_PRANSWER work for you?
>>>
>>> IMO, it is better to define it explicitly in JSEP that "l= atest ANSWER
>>to the offer will replace the existing answer is the expected behav= ior
>>". Also, Please mentioned that JS application is responsible f= or
>>discarding (terminating) previous ANSWER notification. =C2=A0 Pleas= e let me
>>your opinion on this closure.
>>>
>>> Thanks
>>> Partha
>>>
>>> From: Justin Uberti [mailto:juberti@google.com]
>>> Sent: Tuesday, February 14, 2012 7:29 PM
>>> To: Ravindran, Parthasarathi
>>> Cc: rtcweb@ietf.org; public-webrtc@w3.org
>>> Subject: Re: Single offer with multiple answer handling in JSE= P [was
>>RE: [rtcweb] New JSEP draft posted]
>>>
>>> Regarding your previous mail, an ANSWER after an ANSWER would = either
>>fail (if we wanted to simplify), or replace the previous ANSWER
>>(essentially the same as if you had done setLocalDescription(OFFER,=
>>localDescription) followed by setRemoteDescription(ANSWER, answer2)= .
>>>
>>> In no case would it mix the descriptions/media from both answe= rs.
>>>
>>> Other comments inline below.
>>>
>>> On Tue, Feb 14, 2012 at 1:24 AM, Ravindran, Parthasarathi
>><pravindran@sonusnet.= com> wrote:
>>> Hi Justin,
>>>
>>> Adding to my earlier mail, In case answer2 SDP is updated in o= fferer1
>>browser without notifying answerer1, then answer1 will continue to<= br> >>transmit RTP which may not be desired behavior. IMO, we need to def= ine
>>this behavior clearly in offerer side. Some of the possible solutio= ns
>>are
>>>
>>> 1) =C2=A0 =C2=A0 =C2=A0offerer1 has to send atleast RTCP BYE p= ackets towards
>>answerer1 while accepting the answerer2 SDP.
>>>
>>> 2) =C2=A0 =C2=A0 =C2=A0Throw callback to clear answer1 SDP tow= ards offererJS.
>>>
>>>
>>> The application which called setRemoteDescription twice should= have
>>the best idea about what is going on, and therefore is responsible = for
>>notifying answerer1 that its answer has been discarded, if it makes=
>>sense to do so. No callback should be needed here.
>>>
>>>
>>> Please let me know your opinion here.
>>>
>>> Thanks
>>> Partha
>>>
>>> From: Ravindran, Parthasarathi
>>> Sent: Tuesday, February 14, 2012 12:07 AM
>>> To: 'Justin Uberti'; rtcweb@ietf.org; public-webrt= c@w3.org
>>> Subject: Single offer with multiple answer handling in JSEP [w= as RE:
>>[rtcweb] New JSEP draft posted]
>>>
>>> Hi Justin,
>>>
>>> In the draft, it is not spelled out explicitly what is the exp= ected
>>behavior in offerer browser in case multiple answer is received for=
>>single offer. Offer/answer exchange in offerer is as follows:
>>>
>>> OffererJS->OffererUA: var offer =3D pc.createOffer(null); >>> OffererJS->OffererUA: pc.setLocalDescription(SDP_OFFER, off= er);
>>> OffererJS->OffererUA: =C2=A0pc.setRemoteDescription(SDP_ANS= WER, answer1);
>>> OffererUA->Answerer1UA: <media>
>>> OffererJS->OffererUA: =C2=A0pc.setRemoteDescription(SDP_ANS= WER, answer2);
>>> OffererUA->Answerer?UA: <media>?
>>>
>>> My understanding is that "answer2" will update "= ;answer1" in browser
>>and starting sending/receiving media towards answer2 media IP and p= ort.
>>Could you please explain the expected behavior in offerer browser >>whether it updates the media stream based on the last answer or mix= es
>>both answerer.
>>>
>>> Thanks
>>> Partha
>>>
>>> From: rtcweb-bounce= s@ietf.org [mailto:rtcweb-bo= unces@ietf.org] On
>>Behalf Of Justin Uberti
>>> Sent: Thursday, February 09, 2012 2:27 AM
>>> To: rtcweb@ietf.org; public-webrtc@w3.org
>>> Subject: [rtcweb] New JSEP draft posted
>>>
>>> Now available at http://www.ietf.org/id/draft-uberti-rtcwe= b-jsep-
>>01.txt
>>>
>>> Includes changes based on implementation feedback, and I belie= ve it
>>addresses most of the concerns raised in last week's interim me= etings:
>>> - Initial documentation provided for each API call, and what s= tate
>>changes it causes
>>> - More examples, including a complete basic sample application=
>>> - Simplified approach to trickle candidate handling
>>> - Resolved concerns about how to separate SDP attributes into = media /
>>transport
>>> - Provided encapsulation for SDP blobs and ICE candidate lines= , in
>>> the
>>event we want to change encodings or provide helper functions for J= S
>>> - Provided mechanism for limiting candidates to TURN-only
>>> - Resolved several implementation issues
>>>
>>> I have not yet addressed the non-overlapping codec concern men= tioned
>>in the interim meeting. I think there are ways of handling this eit= her
>>in the application or the implementation, but I wanted to get this = -01
>>out first for feedback.
>>>
>>>
>>>
>>> _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb


--00235429d37463f4aa04b91fce82-- From juberti@google.com Thu Feb 16 18: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 6B8B821E8048 for ; Thu, 16 Feb 2012 18:49:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.745 X-Spam-Level: X-Spam-Status: No, score=-102.745 tagged_above=-999 required=5 tests=[AWL=0.231, 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 fGINBX6vG3I4 for ; Thu, 16 Feb 2012 18:49:30 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1F72D21E801C for ; Thu, 16 Feb 2012 18:49:30 -0800 (PST) Received: by qafi29 with SMTP id i29so353631qaf.10 for ; Thu, 16 Feb 2012 18:49:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=69AsRI+DKwL9sPUI5CG9TMDLn185XPRpyFLBjM/MZTU=; b=kjbEFO0hSBxC3SeVNDfIrSA4O8mYX8fxyprLFRM/haqMnYesqY7bedltmAFQUcPmdw mTp2/bLq2QCOkdl5lZTtw+bdKRzGXllF2kX+5Ipzr6N8EBzk+D1g7SXKDVNndEIPaSlp tfEYkDgA0WU59gxDfYyNTSN2307fIVIy0rX9w= Received: by 10.229.76.26 with SMTP id a26mr3580300qck.126.1329446969589; Thu, 16 Feb 2012 18:49:29 -0800 (PST) Received: by 10.229.76.26 with SMTP id a26mr3580284qck.126.1329446969316; Thu, 16 Feb 2012 18:49:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.29.195 with HTTP; Thu, 16 Feb 2012 18:49:09 -0800 (PST) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3D87E4E7@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C3D87E4E7@ESESSCMS0356.eemea.ericsson.se> From: Justin Uberti Date: Thu, 16 Feb 2012 21:49:09 -0500 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=00235429e2d45a94f404b91ffef6 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlbAdkp1xWkw7ZqnOXUENBjEgAbg1kKMQv2C/Itbmecx/u6hsTEYwxvP/W04Iw1iTuCXiHHyS2RdLrrm0dkbv6l4/H88kE3UV6iCEWZx25EABPlS44I80dl4nhyNv6JqMb9l8UFR6Q5MgxiKmUrHV8q8EWfjQ== Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] Joint JSEP draft posted 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, 17 Feb 2012 02:49:34 -0000 --00235429e2d45a94f404b91ffef6 Content-Type: text/plain; charset=UTF-8 Thanks for your questions. As they came in as I was preparing -02 for publication, I did not try to resolve them in -02. On Thu, Feb 16, 2012 at 1:22 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > ** > Hi, > > Yesterday I sent out some questions on jsep-01, and I do believe they > apply also to -02. > > JSEP-01: SDP_PRANSWER and FEDEX use-case > JSEP-01: Associating ICE candidates with m- lines > JSEP-01: Release of non-needed ICE candidates > > Regards, > > Christer > > ------------------------------ > *From:* rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] *On > Behalf Of *Justin Uberti > *Sent:* 16. helmikuuta 2012 7:54 > *To:* public-webrtc@w3.org; rtcweb@ietf.org > *Cc:* Cullen Jennings (fluffy) > *Subject:* [rtcweb] Joint JSEP draft posted > > I've just uploaded a -02 version of the JSEP draft, to which Cullen > Jennings has agreed to sign on as a co-author. This draft includes a few > specific changes suggested by Cullen to ensure that JSEP can be used to > create applications that are RFC 3264-compliant, if desired. > > The draft is available at > http://tools.ietf.org/html/draft-uberti-rtcweb-jsep-02. Please refer to > this latest version of the document when responding to the JSEP call for > consensus. > > Best regards, > --justin > > --00235429e2d45a94f404b91ffef6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for your questions. As they came in as I was preparing -02 for publi= cation, I did not try to resolve them in -02.

On Thu, Feb 16, 2012 at 1:22 AM, Christer Holmberg &= lt;christer.holmberg@eric= sson.com> wrote:
Hi,
=C2=A0
Yesterday I sent out some questions on jsep-01, and I do=20 believe they apply also to -02.
=C2=A0
JSEP-01: SDP_PRANSWER and FEDEX=20 use-case
JSEP-01: Associating ICE candidates with m-=20 lines
JSEP-01: Release of non-needed ICE=20 candidates
=C2=A0
Regards,
=C2=A0
Christer

From: rtcweb-bounces@ietf.org=20 [mailto:rtcweb= -bounces@ietf.org] On Behalf Of Justin=20 Uberti
Sent: 16. helmikuuta 2012 7:54
To:=20 public-webrtc@w3.= org; rtcweb@ietf.o= rg
Cc: Cullen Jennings=20 (fluffy)
Subject: [rtcweb] Joint JSEP draft=20 posted

I've just uploaded a -02 version of the JSEP draft, to which= Cullen=20 Jennings has agreed to sign on as a co-author. This draft includes a few=20 specific changes suggested by Cullen to ensure that JSEP can be used to cre= ate=20 applications that are RFC 3264-compliant, if desired.=C2=A0

The draft is available at=C2=A0http://tools.ietf.org/html/dr= aft-uberti-rtcweb-jsep-02.=C2=A0Please=20 refer to this latest version of the document when responding to the JSEP ca= ll=20 for consensus.

Best regards,
--justin


--00235429e2d45a94f404b91ffef6-- From juberti@google.com Thu Feb 16 18: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 AEF3821E801C for ; Thu, 16 Feb 2012 18:52:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.751 X-Spam-Level: X-Spam-Status: No, score=-102.751 tagged_above=-999 required=5 tests=[AWL=0.225, 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 l-fjaGxYCrjA for ; Thu, 16 Feb 2012 18:52:42 -0800 (PST) Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id F17DB21F847D for ; Thu, 16 Feb 2012 18:52:40 -0800 (PST) Received: by qan41 with SMTP id 41so3135666qan.10 for ; Thu, 16 Feb 2012 18:52:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=8joky26ty8An1FXZIcy0TwGftM7GqgWYdTIXPi/lIL4=; b=nWn5UK385Pj7AnfOi1RKoHOVM/x7eyHRLpdCpogEW5lBjM8z0ZeWSWwk5FvYRrceN4 22s3Czap0MwHK3nuapqXQDqOdH5/cxsy3MR/CTFo84IJ7scRcRKVBWAN0oIzZWAEPTo/ SddI4Do4+WJRbvXVQdGKuZFdxMQx15k7Q8EE4= Received: by 10.229.77.85 with SMTP id f21mr3430478qck.146.1329447160478; Thu, 16 Feb 2012 18:52:40 -0800 (PST) Received: by 10.229.77.85 with SMTP id f21mr3430470qck.146.1329447160304; Thu, 16 Feb 2012 18:52:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.29.195 with HTTP; Thu, 16 Feb 2012 18:52:20 -0800 (PST) In-Reply-To: References: From: Justin Uberti Date: Thu, 16 Feb 2012 21:52:20 -0500 Message-ID: To: Bernard Aboba Content-Type: multipart/alternative; boundary=002354471080bcd37b04b92009be X-System-Of-Record: true X-Gm-Message-State: ALoCoQkU+7iqpOzB4pOSFE6nOWNIzsyvKn3FgW9m+9UmRvp03ojjW6KBa08k8SAl6Oe8++oTx4rsS388qWQn/xh7dRHEwFeSMHnBzq+zLm/J4qKOBpImgtX9fUwV8tozgsStDwqzkvpXZ7b2va+NzvNoFJFXz9dAfg== Cc: rtcweb@ietf.org Subject: Re: [rtcweb] JSEP: "simple" SDP subset? 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, 17 Feb 2012 02:52:47 -0000 --002354471080bcd37b04b92009be Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Feb 16, 2012 at 8:02 PM, Bernard Aboba w= rote: > While it=E2=80=99s true that JSEP is a step forward compared with the pre= vious > API, there Is still something that bothers me about using SDP in the API: > do we understand what SDP subset will be supported by JSEP > implementations? Or are we setting ourselves up for a nasty > interoperability problem? > I think this is pretty important to nail down; as we've gotten down into the details, we've realized that we don't all mean the same thing when we consider how we will represent "multiple video sources" or "video resolution negotiation" in SDP. I think http://tools.ietf.org/html/draft-cbran-rtcweb-protocols-00 was a good first step regarding what WebRTC v1 "Baseline" should include, but we need to be considerably more specific. > **** > > ** ** > > When people talk about SDP on this list, they refer to RFC 3264 > offer/answer, but typically don=E2=80=99t mention all the SDP extension d= ocuments > that have had inconsistent takeup since then. This is a bit like having= a > parent show off a baby picture of their child, saying =E2=80=9Cisn=E2=80= =99t she cute?=E2=80=9D > while neglecting to mention that the picture is 30 years old, and that th= e > =E2=80=9Cbaby=E2=80=9D is now living in a trailer in North Dakota with th= eir 5th husband, > 8 children, and 6 cats. **** > > ** ** > > One of the things I like about JSEP is that the SDP produced by > createOffer() could conceivably be simpler than what you=E2=80=99d send o= ver the > wire, because it=E2=80=99s just an expression of capabilities, not necess= arily a > full-fledged =E2=80=9Coffer=E2=80=9D. For example, if we were dealing w= ith a browser that > could support RTP, SRTP, AVP and AVPF, createOffer () wouldn=E2=80=99t ha= ve to > express everything in RFC 5939 syntax, even if that is what was eventuall= y > sent. All the application needs is a list of capabilities expressed in S= DP > from which it could compose an offer itself. **** > > ** ** > > However, while the SDP produced and consumed by JSEP can be =E2=80=9Csimp= ler=E2=80=9D, > things can get complicated in a hurry. For example:**** > > ** ** > > **a. **What if the user purchased a camera supporting layered > video? This is not a hypothetical, these cameras are on the market. Do = we > know what the m lines look like?**** > > **b. **What if the browser can support RTP, SRTP, AVP and AVPF? > Does createOffer() just use the most sophisticated profile (e.g. RTP/SAVP= F) > to keep things simple, letting the application decide what profile to > include (e.g. RTP/SAVP if the responder is a legacy device unlikely to > understand RTP/SAVPF, or capneg if the responder is likely to understand > it)?**** > > **c. **What if the browser supports multiple security schemes (e.g. > SRTP/SDES and DTLS/SRTP)? What does the output of createOffer() look lik= e? > **** > > ** ** > > I am *hoping* that JSEP will never need to utilize RFC 5939 semantics in > the SDP blobs it produces or consumes, but I can understand if it **may** > need to utilize SDP extensions not yet standardized (e.g. SRCNAME). **** > > ** ** > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --002354471080bcd37b04b92009be Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Feb 16, 2012 at 8:02 PM, Bernard= Aboba <b= ernard_aboba@hotmail.com> wrote:

While it=E2=80=99s true that JSEP is a step forward compared with the p= revious API, there Is still something that bothers me about using SDP in th= e API:=C2=A0 do we understand what SDP subset will be supported by JSEP imp= lementations?=C2=A0 Or are we setting ourselves up for a nasty interoperabi= lity problem?


I think this is pretty importa= nt to nail down; as we've gotten down into the details, we've reali= zed that we don't all mean the same thing when we consider how we will = represent "multiple video sources" or "video resolution nego= tiation" in SDP.

I think=C2=A0http://tools.ietf.org/html/draft-cbran-rtcweb-= protocols-00=C2=A0was a good first step regarding what WebRTC v1 "= Baseline" should include, but we need to be considerably more specific= .

=C2=A0

When people talk about SDP on this list, they refer = to RFC 3264 offer/answer, but typically don=E2=80=99t mention all the SDP e= xtension documents that have had inconsistent takeup since then. =C2=A0=C2= =A0This is a bit like having a parent show off a baby picture of their chil= d, saying =E2=80=9Cisn=E2=80=99t she cute?=E2=80=9D while neglecting to men= tion that the picture is 30 years old, and that the =E2=80=9Cbaby=E2=80=9D = is now living in a trailer in North Dakota with their 5th husban= d, 8 children, and 6 cats.

=C2=A0

One o= f the things I like about JSEP is that the SDP produced by createOffer() co= uld conceivably be simpler than what you=E2=80=99d send over the wire, beca= use it=E2=80=99s just an expression of capabilities, not necessarily a full= -fledged =E2=80=9Coffer=E2=80=9D. =C2=A0=C2=A0For example, if we were deali= ng with a browser that could support RTP, SRTP, AVP and AVPF, createOffer (= ) wouldn=E2=80=99t have to express everything in RFC 5939 syntax, even if t= hat is what was eventually sent.=C2=A0 All the application needs is a list = of capabilities expressed in SDP from which it could compose an offer itsel= f.=C2=A0

=C2=A0

Howev= er, while the SDP produced and consumed by JSEP can be =E2=80=9Csimpler=E2= =80=9D, things can get complicated in a hurry.=C2=A0 For example:=

=C2=A0

a.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 What if the user purchased a camera supporting layered video?=C2=A0 Th= is is not a hypothetical, these cameras are on the market. =C2=A0Do we know= what the m lines look like?

b.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 What if the browser can= support RTP, SRTP, AVP and AVPF?=C2=A0 Does createOffer() just use the mos= t sophisticated profile (e.g. RTP/SAVPF) to keep things simple, letting the= application decide what profile to include (e.g. RTP/SAVP if the responder= is a legacy device unlikely to understand RTP/SAVPF, or capneg if the resp= onder is likely to understand it)?

c.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 What if the brows= er supports multiple security schemes (e.g. SRTP/SDES and DTLS/SRTP)?=C2=A0= What does the output of createOffer() look like?

=C2=A0

I am = hoping that JSEP will never need to utilize RFC 5939 semantic= s in the SDP blobs it produces or consumes, but I can understand if it *= may* need to utilize SDP extensions not yet standardized (e.g. SRCNAME)= .

=C2=A0


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


--002354471080bcd37b04b92009be-- From juberti@google.com Thu Feb 16 19:00: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 AC14C21E8056 for ; Thu, 16 Feb 2012 19:00:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.756 X-Spam-Level: X-Spam-Status: No, score=-102.756 tagged_above=-999 required=5 tests=[AWL=0.220, 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 hCeGHMPR8eCF for ; Thu, 16 Feb 2012 19:00:20 -0800 (PST) Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 42AA321E8024 for ; Thu, 16 Feb 2012 19:00:20 -0800 (PST) Received: by qan41 with SMTP id 41so3140564qan.10 for ; Thu, 16 Feb 2012 19:00:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=XteMfbNrtbw86zr6IMVqkHC4CV70ExWa8Jh0l5FWGPs=; b=JemGymgSbaHqWPJ/VgvtZw6NueP5qvXB/KvlfJZjoNbfUZlVdktDeOMStNs26+q7Sx 2KbuH9g/MOcGfD9RYPIyVkq66WnHgFQvzNqAUmRGwZfKy4TbC1wiMGksNRYIv+jqXfy0 JQv5AVzFRaj+xH6e1vWQtx74zd693Iim+NZ80= Received: by 10.229.77.85 with SMTP id f21mr3446283qck.146.1329447619565; Thu, 16 Feb 2012 19:00:19 -0800 (PST) Received: by 10.229.77.85 with SMTP id f21mr3446261qck.146.1329447619358; Thu, 16 Feb 2012 19:00:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.29.195 with HTTP; Thu, 16 Feb 2012 18:59:59 -0800 (PST) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3D31BA27@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C3D87E29E@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C3D31BA27@ESESSCMS0356.eemea.ericsson.se> From: Justin Uberti Date: Thu, 16 Feb 2012 21:59:59 -0500 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=00235447108019714904b92025dd X-System-Of-Record: true X-Gm-Message-State: ALoCoQnk39ak1QmeGCmBpUgJn1iwl/VZCuOSqQ5A7e7GO83RT4V4M3CwpKBorV2bKJUHF+7UpOK8gGGvV/dY3H56rdAZgLO8Xg2MrZPLdozUZdrJeLeZYCd9XYwpJ9N1y0+wreJ5I8Qqi5RNhhGeUgu7Xfg0WBzWbA== Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] JSEP-01: Release of non-needed ICE candidates 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, 17 Feb 2012 03:00:24 -0000 --00235447108019714904b92025dd Content-Type: text/plain; charset=UTF-8 On Wed, Feb 15, 2012 at 12:28 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > > Hi, > > My use-case is not about whether the app wants turn candidates or not - it > is about that fact that it at some point decides to send the SIP SDP offer > towards the remote party, even if it has not received all candidates that > is previously specified. > > Maybe the browser, due to some network and/or configuration error, isn't > even able to contact a turn server. Will it inform the app about that, or > will it simply not provide turn candidates? > Right now, it will simply not provide STUN or TURN candidates if it can't contact the appropriate server. > > Regards, > > Christer > > ________________________________________ > From: Jim Barnett [Jim.Barnett@genesyslab.com] > Sent: Wednesday, February 15, 2012 5:43 PM > To: Christer Holmberg; rtcweb@ietf.org; public-webrtc@w3.org > Subject: RE: [rtcweb] JSEP-01: Release of non-needed ICE candidates > > In section 6.1.9 of the latest JSEP draft, the startICE() function allows > the JS app to specify which types of candidates it wants, so your app can > avoid getting turn candidates in the first place. I would also assume that > the browser could/would release un-needed resources when > setRemoteDescription is called. > > > - Jim > > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf > Of Christer Holmberg > Sent: Wednesday, February 15, 2012 9:27 AM > To: rtcweb@ietf.org; public-webrtc@w3.org > Subject: [rtcweb] JSEP-01: Release of non-needed ICE candidates > > > Hi, > > Assume my SIP JS app gets an offer, and some ICE candidatates, generates > and sends a SIP SDP offer. > > Later, the browser provides additional ICE candidates (using the ice > callback function). > > My SIP JS app is not interested in the additional ICE candidates. > > Q1: Is it possible for the JS app to inform the browser that it does not > need the additional ICE candidates? For example, if my app is given turn > candidates, which I am not going to use (read: offer to the remote party), > there is really no need for the browser to maintain the connection with the > turn server. > > Q2: Do we assume that the browser at some point (e.g. when the associated > answer is provided) will be able to release resources associated with > non-needed ICE candidates? > > Regards, > > Christer > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --00235447108019714904b92025dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Feb 15, 2012 at 12:28 PM, Christ= er Holmberg <christer.holmberg@ericsson.com> wrote:

Hi,

My use-case is not about whether the app wants turn candidates or not - it = is about that fact that it at some point decides to send the SIP SDP offer = towards the remote party, even if it has not received all candidates that i= s previously specified.

Maybe the browser, due to some network and/or configuration error, isn'= t even able to contact a turn server. Will it inform the app about that, or= will it simply not provide turn candidates?

Right now, it will simply not provide STUN or TURN candidates if= it can't contact the appropriate server.
=C2=A0

Regards,

Christer

________________________________________
From: Jim Barnett [Jim.Barnet= t@genesyslab.com]
Sent: Wednesday, February 15, 2012 5:43 PM
To: Christer Holmberg; rtcweb@ietf.org; public-webrtc@w3.org
Subject: RE: [rtcweb] JSEP-01: Release of non-needed ICE candidates

In section 6.1.9 of the latest JSEP draft, the startICE() function allows t= he JS app to specify which types of candidates it wants, =C2=A0so your app = can avoid getting turn candidates in the first place. =C2=A0I would also as= sume that the browser could/would release un-needed resources when setRemot= eDescription is called.


- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jim

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.or= g] On Behalf Of Christer Holmberg
Sent: Wednesday, February 15, 2012 9:27 AM
To: rtcweb@ietf.org; public-webrtc@w3.org
Subject: [rtcweb] JSEP-01: Release of non-needed ICE candidates


Hi,

Assume my SIP JS app gets an offer, and some ICE candidatates, generates an= d sends a SIP SDP offer.

Later, the browser provides additional ICE candidates (using the ice callba= ck function).

My SIP JS app is not interested in the additional ICE candidates.

Q1: Is it possible for the JS app to inform the browser that it does not ne= ed the additional ICE candidates? For example, if my app is given turn cand= idates, which I am not going to use (read: offer to the remote party), ther= e is really no need for the browser to maintain the connection with the tur= n server.

Q2: Do we assume that the browser at some point (e.g. when the associated a= nswer is provided) will be able to release resources associated with non-ne= eded ICE candidates?

Regards,

Christer

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

--00235447108019714904b92025dd-- From christer.holmberg@ericsson.com Thu Feb 16 22:56: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 CE40921F8617 for ; Thu, 16 Feb 2012 22:56:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.412 X-Spam-Level: X-Spam-Status: No, score=-9.412 tagged_above=-999 required=5 tests=[AWL=0.587, BAYES_00=-2.599, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mLE9OWW5c51O for ; Thu, 16 Feb 2012 22:56:32 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id A490021F8602 for ; Thu, 16 Feb 2012 22:56:31 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-40-4f3dfa1ec0f1 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id DB.5E.27041.E1AFD3F4; Fri, 17 Feb 2012 07:56:30 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Fri, 17 Feb 2012 07:56:30 +0100 From: Christer Holmberg To: Justin Uberti Date: Fri, 17 Feb 2012 07:56:29 +0100 Thread-Topic: [rtcweb] JSEP-02: Associating ICE candidates with m- lines Thread-Index: AcztGzXr+EGoGMojS5qcpEgXfOsj7QAJKoQA Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3D8C59FE@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C3D87E075@ESESSCMS0356.eemea.ericsson.se> 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 X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] JSEP-02: Associating ICE candidates with m- lines 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, 17 Feb 2012 06:56:32 -0000 Hi, =20 >> In jsep-01, an "m- line reference" has been added to the a=3Dcandidate a= ttribute, in order=20 >> for the browser to indicate for which m- line the attribute belongs to. >> =20 >> Q1: As, within a session, as new SDP offers may be sent (and, as least i= n theory I=20 >> assume, new local candidates may be provided), I wonder whether it, in a= ddition to=20 >> the m- line reference, also would be useful to include an SDP version re= ference=20 >> (found the SDP o- line)? >=09 > > Need to think through the exact scenario where this would come into play,= but it seems=20 > useful. If you have a flow in mind, I'd be interested in seeing it. I guess it depends on when the browser would stop collecting candidates for= an offer. Take the following example: 1. The JS app creates an offer (o-1). 2. The JS app gets some candidates using the ice callback function. 3. The JS app sends the offer over-the-wire as an 3264 offer. 4. The JS app receives an 3264 answer, and gives it (and the associated can= didates) to the browser. 5. The JS app creates a NEW offer (0-2). 6. The JS app gets some candidates using the ice callback function. Now, the question is: once the JS app has created the new offer (o-2), can = it still receive=20 candidates for the old offer (o-1)? IF so, there MAY be a need to make the = distinction (depending=20 on how the new and old offer vary from each other). OR, does the browser stop collecting candidates for a given offer, once at = least one associated=20 answer has been provided? =20 >> Q2: If BUNDLE is used, multiple m- lines may share the same candidates, = so it should be possible=20 >> to indicate that an a=3Dcandidate attribute belongs to multiple m- lines= - AND/OR to indicate that=20 >> it belongs to a given bundle group. >=09 > > In this case I was going to have the IceCallback fire twice with the same= candidate, once for=20 > each m=3D line. I think this is the simplest approach, but let me know if= you see an issue with it.=20 In my opinion a single IceCallback would be simpler. Otherwise the app deve= loper has to consider the case where it would not - for whatever strange re= ason - receive candidates for every m- line associated with the BUNDLE, AND= /OR it would receive different candidates. That should of course not happen= in normal situations, but a single callback would mean the app developer d= oesn't even have to think about it. Regards, Christer From christer.holmberg@ericsson.com Thu Feb 16 23: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 8254D21F88B0 for ; Thu, 16 Feb 2012 23:40:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.731 X-Spam-Level: X-Spam-Status: No, score=-9.731 tagged_above=-999 required=5 tests=[AWL=0.868, 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 gCXGrz8pxOz1 for ; Thu, 16 Feb 2012 23:40:49 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF6121F8818 for ; Thu, 16 Feb 2012 23:40:48 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-d2-4f3e047e7975 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id E9.16.01970.E740E3F4; Fri, 17 Feb 2012 08:40:47 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Fri, 17 Feb 2012 08:40:46 +0100 From: Christer Holmberg To: Bernard Aboba , "rtcweb@ietf.org" Date: Fri, 17 Feb 2012 08:40:46 +0100 Thread-Topic: [rtcweb] JSEP: "simple" SDP subset? Thread-Index: AcztDy8+bauT6vMrTXKPx12qwuMJqAANDmvQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3D8C5A4F@ESESSCMS0356.eemea.ericsson.se> 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 X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] JSEP: "simple" SDP subset? 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, 17 Feb 2012 07:40:49 -0000 Hi,=20 > While it's true that JSEP is a step forward compared with the previous AP= I, there Is still something=20 > that bothers me about using SDP in the API: do we understand what SDP su= bset will be supported by=20 > JSEP implementations? Or are we setting ourselves up for a nasty interop= erability problem? > > When people talk about SDP on this list, they refer to RFC 3264 offer/ans= wer, but typically don't mention=20 > all the SDP extension documents that have had inconsistent takeup since t= hen. This is a bit like having a=20 > parent show off a baby picture of their child, saying "isn't she cute?" w= hile neglecting to mention that=20 > the picture is 30 years old, and that the "baby" is now living in a trail= er in North Dakota with their=20 > 5th husband, 8 children, and 6 cats.=20 > > One of the things I like about JSEP is that the SDP produced by createOff= er() could conceivably be simpler=20 > than what you'd send over the wire, because it's just an expression of ca= pabilities, not necessarily a=20 > full-fledged "offer". For example, if we were dealing with a browser th= at could support RTP, SRTP, AVP=20 > and AVPF, createOffer () wouldn't have to express everything in RFC 5939 = syntax, even if that is what was > eventually sent. All the application needs is a list of capabilities exp= ressed in SDP from which it could=20 > compose an offer itself. =20 > > However, while the SDP produced and consumed by JSEP can be "simpler", th= ings can get complicated in a hurry. For example: > > > a. What if the user purchased a camera supporting layered video? This is= not a hypothetical, these cameras are on the market. Do we know what the = m lines look like? > > b. What if the browser can support RTP, SRTP, AVP and AVPF? Does createO= ffer() just use the most sophisticated profile (e.g. RTP/SAVPF) to keep thi= ngs simple, letting the application decide=20 > what profile to include (e.g. RTP/SAVP if the responder is a legacy devic= e unlikely to understand RTP/SAVPF, or capneg if the responder is likely to= understand it)? > > c. What if the browser supports multiple security schemes (e.g. SRTP/SDES= and DTLS/SRTP)? What does the output of createOffer() look like?=20 > > > I am hoping that JSEP will never need to utilize RFC 5939 semantics in th= e SDP blobs it produces or consumes, but I can > understand if it *may* need to utilize SDP extensions not yet standardize= d (e.g. SRCNAME).=20 In my opinion, the "hints" could be use by the JS app to indicate what SDP = extensions it is able/willing to handle.=20 That way, even if the browser/API supports all the SDP extensions in the wo= rld, a simple app would not have to. Regards, Christer =20 From christer.holmberg@ericsson.com Fri Feb 17 00:33: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 5B51721F8832 for ; Fri, 17 Feb 2012 00:33:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.757 X-Spam-Level: X-Spam-Status: No, score=-9.757 tagged_above=-999 required=5 tests=[AWL=0.842, 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 zU6RdRtZ0Xne for ; Fri, 17 Feb 2012 00:33:58 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 7B4EC21F8831 for ; Fri, 17 Feb 2012 00:33:58 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-2b-4f3e10f5bfbc Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id E0.7E.27041.5F01E3F4; Fri, 17 Feb 2012 09:33:57 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Fri, 17 Feb 2012 09:33:57 +0100 From: Christer Holmberg To: Justin Uberti Date: Fri, 17 Feb 2012 09:33:55 +0100 Thread-Topic: [rtcweb] JSEP-01: SDP_PRANSWER and FEDEX use-case Thread-Index: AcztGk2Xf5AiFU7GSsyeeU8CnprC1QAMxIhA Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3D8C5AD8@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C3D87E060@ESESSCMS0356.eemea.ericsson.se> 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 X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] JSEP-01: SDP_PRANSWER and FEDEX use-case 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, 17 Feb 2012 08:33:59 -0000 Hi,=20 =20 >> Section 6.1.4 of jsep-01 says: >> =20 >> "SDP_PRANSWER indicates that a description should be parsed as a= n >> answer, but not a final answer, and so should not result in the >> starting of media transmission. A description used as a SDP_PRA= NSWER >> may be applied as a response to a SDP_OFFER, or an update to a >> previously sent SDP_PRANSWER." >> =20 >> =20 >> Section 7.6 shows a SIP early media (FEDEX) use-case, where an SDP answe= r received in a SIP 18x response is provided to the browser as a SDP_PRANSW= ER. >> =20 >> =20 >> Q1: Since SDP_PRANSWER is not supposed to start media transmission, how = will the use-case work? As far as I know, media transmission is needed for = the FEDEX use-case. >=09 > > I think this is just me being unclear. When I say "start media transmissi= on", I mean that when the browser gets a SDP_PRANSWER=20 > in response to an offer, the browser will not start transmitting media. H= owever, it will play out any media that is received=20 > after the offer is installed, and the gateway can start sending media at = any time after it gets the offer. Again, you could achieve that using SDP_ANSWER and a direction attribute (a= =3Drecvonly). I don't think we need SDP_PRANSWER for unidirectional media p= urpose. (And, as was mentioned, there may actually be a need to also transmit media= for the FEDEX case) =20 >> Q2: The draft doesn't really specify what SDP_PRANSWER is used for. I un= derstand that it means that a "final" answer >> may be provided later, but it doesn't really say what the a browser woul= d do with an SDP_PRANSWER - especially since=20 >> it doesn't seem to enable media. >=09 > > SDP_PRANSWER allows, among other things, the callee's ICE and SRTP info t= o be provided so that early media can=20 > be received by the caller. I think it should make more sense given my ans= wer to #1. As I replied to #1, I don't think we need SDP_PRANSWER to establish unidire= ctional media, so I would like to know what those "other things" are :) =20 >> Q3: Assuming we would allow multiple SDP_ANSWER (see separate thread), i= s there a need for SDP_PRANSWER? >=09 > > SDP_PRANSWER has slightly different semantics in that it is not intended = to indicate consent by the callee, whereas SDP_ANSWER does.=20 What does the browser do with that information? My understanding was that the browser is going to use media plane mechanism= s (e.g. ICE) for callee consent. Regards, Christer From andrew.hutton@siemens-enterprise.com Fri Feb 17 02:33:03 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 D47F821F8566 for ; Fri, 17 Feb 2012 02:33:03 -0800 (PST) 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 5530eWornXmW for ; Fri, 17 Feb 2012 02:33:03 -0800 (PST) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id AA50621F851B for ; Fri, 17 Feb 2012 02:33:02 -0800 (PST) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id A4E4E23F0516; Fri, 17 Feb 2012 11:33:01 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 17 Feb 2012 11:33:02 +0100 From: "Hutton, Andrew" To: Christer Holmberg , Bernard Aboba , "rtcweb@ietf.org" Date: Fri, 17 Feb 2012 11:33:00 +0100 Thread-Topic: [rtcweb] JSEP: "simple" SDP subset? Thread-Index: AcztDy8+bauT6vMrTXKPx12qwuMJqAANDmvQAAZnxxA= Message-ID: <101C6067BEC68246B0C3F6843BCCC1E31202EDA878@MCHP058A.global-ad.net> References: <7F2072F1E0DE894DA4B517B93C6A05852C3D8C5A4F@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3D8C5A4F@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 Subject: Re: [rtcweb] JSEP: "simple" SDP subset? 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, 17 Feb 2012 10:33:04 -0000 Hi, >=20 > > While it's true that JSEP is a step forward compared with the > previous API, there Is still something > > that bothers me about using SDP in the API: do we understand what > SDP subset will be supported by > > JSEP implementations? Or are we setting ourselves up for a nasty > interoperability problem? > > > > When people talk about SDP on this list, they refer to RFC 3264 > offer/answer, but typically don't mention > > all the SDP extension documents that have had inconsistent takeup > since then. This is a bit like having a > > parent show off a baby picture of their child, saying "isn't she > cute?" while neglecting to mention that > > the picture is 30 years old, and that the "baby" is now living in a > trailer in North Dakota with their > > 5th husband, 8 children, and 6 cats. > > > > One of the things I like about JSEP is that the SDP produced by > createOffer() could conceivably be simpler > > than what you'd send over the wire, because it's just an expression > of capabilities, not necessarily a > > full-fledged "offer". For example, if we were dealing with a > browser that could support RTP, SRTP, AVP > > and AVPF, createOffer () wouldn't have to express everything in RFC > 5939 syntax, even if that is what was > > eventually sent. All the application needs is a list of capabilities > expressed in SDP from which it could > > compose an offer itself. > > > > However, while the SDP produced and consumed by JSEP can be > "simpler", things can get complicated in a hurry. For example: > > > > > > a. What if the user purchased a camera supporting layered video? > This is not a hypothetical, these cameras are on the market. Do we > know what the m lines look like? > > > > b. What if the browser can support RTP, SRTP, AVP and AVPF? Does > createOffer() just use the most sophisticated profile (e.g. RTP/SAVPF) > to keep things simple, letting the application decide > > what profile to include (e.g. RTP/SAVP if the responder is a legacy > device unlikely to understand RTP/SAVPF, or capneg if the responder is > likely to understand it)? > > > > c. What if the browser supports multiple security schemes (e.g. > SRTP/SDES and DTLS/SRTP)? What does the output of createOffer() look > like? > > > > > > I am hoping that JSEP will never need to utilize RFC 5939 semantics > in the SDP blobs it produces or consumes, but I can > > understand if it *may* need to utilize SDP extensions not yet > standardized (e.g. SRCNAME). >=20 > In my opinion, the "hints" could be use by the JS app to indicate what > SDP extensions it is able/willing to handle. > That way, even if the browser/API supports all the SDP extensions in > the world, a simple app would not have to. >=20 [Andy] - If a simple app is one that does not have to worry about interwork= ing then I assume it would not care about SDP probably just passing the SDP= blob without change between browsers. However if the app has to handle com= plex interworking scenarios then it really would help if there is a clear d= escription of the SDP profile which the browser supports. It was clear fro= m the discussion at the interim that we need to nail some of the SDP option= s down. Surely the aim should be to keep the SDP subset that the browser needs to s= upport reasonably small and well defined and leave the complicated interwor= king stuff to the applications that need to do that. =20 > Regards, >=20 > Christer >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From pravindran@sonusnet.com Fri Feb 17 05:24: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 A932621F85C5 for ; Fri, 17 Feb 2012 05:24:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.013, 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 HKxU4D9rKuU8 for ; Fri, 17 Feb 2012 05:24:41 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 4E15B21F859A for ; Fri, 17 Feb 2012 05:24:41 -0800 (PST) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q1HDPQvq001226; Fri, 17 Feb 2012 08:25:26 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 17 Feb 2012 08:24:13 -0500 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 17 Feb 2012 18:54:23 +0530 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; Fri, 17 Feb 2012 18:54:23 +0530 From: "Ravindran, Parthasarathi" To: Justin Uberti Thread-Topic: [rtcweb] Single offer with multiple answer handling in JSEP [was RE: New JSEP draft posted] Thread-Index: AQHM67gG55cr02A1XECJjPr/R3Q48ZY9oafAgAF6hICAAOnjAIABEPpQ Date: Fri, 17 Feb 2012 13:24:20 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E0406FA@inba-mail01.sonusnet.com> References: <387F9047F55E8C42850AD6B3A7A03C6C0E03F8A4@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E03FAB5@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E03FB7C@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E03FC20@inba-mail01.sonusnet.com> <9ED4A9AC-37C7-4E6D-B6C6-4D3C9537B356@iii.ca> <387F9047F55E8C42850AD6B3A7A03C6C0E040130@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.70] Content-Type: multipart/alternative; boundary="_000_387F9047F55E8C42850AD6B3A7A03C6C0E0406FAinbamail01sonus_" MIME-Version: 1.0 X-OriginalArrivalTime: 17 Feb 2012 13:24:23.0524 (UTC) FILETIME=[76B31240:01CCED77] Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] Single offer with multiple answer handling in JSEP [was RE: New JSEP draft posted] 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, 17 Feb 2012 13:24:43 -0000 --_000_387F9047F55E8C42850AD6B3A7A03C6C0E0406FAinbamail01sonus_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSnVzdGluLA0KDQpUaGlzIHNvdW5kcyBnb29kIHRvIG1lLiBJ4oCZbGwgc2VuZCB0aGUgZXhh bXBsZSBjYWxsZmxvdyBBU0FQLg0KDQpUaGFua3MNClBhcnRoYQ0KDQpGcm9tOiBKdXN0aW4gVWJl cnRpIFttYWlsdG86anViZXJ0aUBnb29nbGUuY29tXQ0KU2VudDogRnJpZGF5LCBGZWJydWFyeSAx NywgMjAxMiA4OjA2IEFNDQpUbzogUmF2aW5kcmFuLCBQYXJ0aGFzYXJhdGhpDQpDYzogQ3VsbGVu IEplbm5pbmdzOyBydGN3ZWJAaWV0Zi5vcmc7IHB1YmxpYy13ZWJydGNAdzMub3JnDQpTdWJqZWN0 OiBSZTogW3J0Y3dlYl0gU2luZ2xlIG9mZmVyIHdpdGggbXVsdGlwbGUgYW5zd2VyIGhhbmRsaW5n IGluIEpTRVAgW3dhcyBSRTogTmV3IEpTRVAgZHJhZnQgcG9zdGVkXQ0KDQpBZ3JlZSBpdCBoYXMg bm90IGJlZW4gYWRkcmVzc2VkLiBJJ20gaGF2aW5nIHNvbWUgdHJvdWJsZSB1bmRlcnN0YW5kaW5n IHRoZSBleGFjdCBmbG93cyB0aGF0IHdlIG5lZWQgdG8gYWRkcmVzcyBoZXJlIChtdWx0aXBsZSAy eHgsIG11bHRpcGxlIDE4eCBmb2xsb3dlZCBieSAyeHgsIG11bHRpcGxlIDE4eCBmb2xsb3dlZCBi eSBtdWx0aXBsZSAyeHgpIGJ1dCBpZiBJIHVuZGVyc3RhbmQgY29ycmVjdGx5IHlvdXIgc3VnZ2Vz dGlvbiB3YXM6DQoNCjEpIGFsbG93IGEgc2V0UmVtb3RlRGVzYyhTRFBfQU5TV0VSKSB0byBmb2xs b3cgYSBzZXRSZW1vdGVEZXNjKFNEUF9BTlNXRVIpDQoyKSBkb2N1bWVudCB0aGF0IGluIHRoaXMg Y2FzZSAobXVsdGlwbGUgMnh4KSwgdGhlIEpTIGlzIHJlc3BvbnNpYmxlIGZvciBzZW5kaW5nIEJZ RSB0byB0aGUgcHJldmlvdXMgYW5zd2VyZXIuDQoNCndoaWNoIHNvdW5kcyB0b3RhbGx5IHJlYXNv bmFibGUgdG8gbWUuDQoNCklmIHRoaXMgc291bmRzIGdvb2QgdG8geW91LCB3b3VsZCB5b3UgbWlu ZCBza2V0Y2hpbmcgb3V0IGEgY2FsbCBmbG93IHRoYXQgSSBjb3VsZCBpbmNsdWRlIGluIHRoZSBl eGFtcGxlcyBzZWN0aW9uPw0KDQpPbiBUaHUsIEZlYiAxNiwgMjAxMiBhdCAyOjExIEFNLCBSYXZp bmRyYW4sIFBhcnRoYXNhcmF0aGkgPHByYXZpbmRyYW5Ac29udXNuZXQuY29tPG1haWx0bzpwcmF2 aW5kcmFuQHNvbnVzbmV0LmNvbT4+IHdyb3RlOg0KQ3VsbGVuL0p1c3RpbiwNCg0KU2luZ2xlIG9m ZmVyIHdpdGggbXVsdGlwbGUgYW5zd2VyIG9wZW4gaXRlbSBpcyBub3QgYWRkcmVzc2VkIGluIC0w MiB2ZXJzaW9uIG9mIEpTRVAgZHJhZnQuIEhvcGUgeW91IGZpcnN0IGFncmVlIHRoaXMgYXMgYW4g b3BlbiBpdGVtIGluIEpTRVAuDQoNClRoYW5rcw0KUGFydGhhDQoNCj4tLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPkZyb206IFJhdmluZHJhbiwgUGFydGhhc2FyYXRoaQ0KPlNlbnQ6IFdlZG5l c2RheSwgRmVicnVhcnkgMTUsIDIwMTIgMjo0MyBQTQ0KPlRvOiAnQ3VsbGVuIEplbm5pbmdzJw0K PkNjOiBKdXN0aW4gVWJlcnRpOyBydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9y Zz47IHB1YmxpYy13ZWJydGNAdzMub3JnPG1haWx0bzpwdWJsaWMtd2VicnRjQHczLm9yZz4NCj5T dWJqZWN0OiBSRTogW3J0Y3dlYl0gU2luZ2xlIG9mZmVyIHdpdGggbXVsdGlwbGUgYW5zd2VyIGhh bmRsaW5nIGluIEpTRVANCj5bd2FzIFJFOiBOZXcgSlNFUCBkcmFmdCBwb3N0ZWRdDQo+DQo+Q3Vs bGVuLA0KPg0KPlJGQzMyNjEgcmVmZXJlbmNlcyBmb3IgcmVjZWl2aW5nIG11bHRpcGxlIDJ4eCBp biBVQUMgd2hpY2ggZG9lcyBub3QgZm9yaw0KPklOVklURSBhcmUgYXMgZm9sbG93czoNCj4NCj48 UkZDIHF1b3RlPg0KPlNlYyAxMy4xIFBhcmEgMzoNCj4NCj5UaGVyZWZvcmUsIHdoZW4gbXVsdGlw bGUgMnh4IHJlc3BvbnNlcyBhcmUgcmVjZWl2ZWQgZnJvbSBkaWZmZXJlbnQNCj5yZW1vdGUgVUFz IChiZWNhdXNlIHRoZSBJTlZJVEUgZm9ya2VkKSwgZWFjaCAyeHggZXN0YWJsaXNoZXMgYSBkaWZm ZXJlbnQNCj5kaWFsb2cuICBBbGwgdGhlc2UgZGlhbG9ncyBhcmUgcGFydCBvZiB0aGUgc2FtZSBj YWxsLg0KPg0KPlNlYyAxMy4yLjIuNCAyeHggUmVzcG9uc2VzDQo+DQo+ICAgTXVsdGlwbGUgMnh4 IHJlc3BvbnNlcyBtYXkgYXJyaXZlIGF0IHRoZSBVQUMgZm9yIGEgc2luZ2xlIElOVklURQ0KPiAg IHJlcXVlc3QgZHVlIHRvIGEgZm9ya2luZyBwcm94eS4gIEVhY2ggcmVzcG9uc2UgaXMgZGlzdGlu Z3Vpc2hlZCBieQ0KPiAgIHRoZSB0YWcgcGFyYW1ldGVyIGluIHRoZSBUbyBoZWFkZXIgZmllbGQs IGFuZCBlYWNoIHJlcHJlc2VudHMgYQ0KPiAgIGRpc3RpbmN0IGRpYWxvZywgd2l0aCBhIGRpc3Rp bmN0IGRpYWxvZyBpZGVudGlmaWVyLg0KPg0KPiAgIElmLCBhZnRlciBhY2tub3dsZWRnaW5nIGFu eSAyeHggcmVzcG9uc2UgdG8gYW4gSU5WSVRFLCB0aGUgVUFDIGRvZXMNCj4gICBub3Qgd2FudCB0 byBjb250aW51ZSB3aXRoIHRoYXQgZGlhbG9nLCB0aGVuIHRoZSBVQUMgTVVTVCB0ZXJtaW5hdGUN Cj4gICB0aGUgZGlhbG9nIGJ5IHNlbmRpbmcgYSBCWUUgcmVxdWVzdCBhcyBkZXNjcmliZWQgaW4g U2VjdGlvbiAxNS4NCj48L1JGQyBxdW90ZT4NCj4NCj5BcyBwZXIgdGhlIGxhc3Qgc3RhdGVtZW50 cywgaXQgaXMgdXB0byB0aGUgU0lQIGFwcGxpY2F0aW9uIHRvIGRlY2lkZQ0KPndoaWNoIG9uZSBv ZiB0aGUgZmluYWwgMnh4IHJlc3BvbnNlIGhhcyB0byBiZSBpbmNsdWRlZCB3aXRoaW4gdGhlIGNh bGwuDQo+VGhlIHVzZWNhc2UgMyBpcyBiYXNlZCBvbiBSRkMzMjYyIChQUkFDSykgc3VwcG9ydCB3 aGVyZWluIGl0IGlzIHBvc3NpYmxlDQo+dG8gcmVjZWl2ZSBtdWx0aXBsZSBmb3JrZWQgMTh4IHdp dGggU0RQIGZvbGxvd2VkIGJ5IDJ4eCB3aXRoIG9yIHdpdGhvdXQNCj5TRFAgYW5kIFNJUCAyeHgg cmVzcG9uc2UgaXMgbm90IHRpZWQgdG8gb2ZmZXIvYW5zd2VyIGV4Y2hhbmdlLg0KPg0KPkkgaGF2 ZSBwcm92aWRlZCBtb2JpbGUgdG8gZGVza3RvcCBhcyBhbiBleGFtcGxlIHRvIGp1c3RpZnkgdGhl IGxhc3QNCj5hbnN3ZXIgbWF5IGJlIHVzZWQgaW4gdGhlIG9mZmVyIGluIHNvbWUgSlMgYXBwbGlj YXRpb24uIEFzIEkgbWVudGlvbmVkDQo+YmVsb3csIHRoZXJlIGlzIG5vIG5lZWQgdG8gcmVzdHJp Y3QgdXBkYXRpbmcgbGF0ZXN0IGFuc3dlciBmb3IgYW4gb2ZmZXINCj5pbiB0ZXJtcyBvZiBBUEkg YW5kIHByb3RvY29sLg0KPg0KPlRoYW5rcw0KPlBhcnRoYQ0KPg0KPj4tLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPj5Gcm9tOiBDdWxsZW4gSmVubmluZ3MgW21haWx0bzpmbHVmZnlAaWlpLmNh PG1haWx0bzpmbHVmZnlAaWlpLmNhPl0NCj4+U2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAxNSwg MjAxMiAxOjMxIFBNDQo+PlRvOiBSYXZpbmRyYW4sIFBhcnRoYXNhcmF0aGkNCj4+Q2M6IEp1c3Rp biBVYmVydGk7IHJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPjsgcHVibGlj LXdlYnJ0Y0B3My5vcmc8bWFpbHRvOnB1YmxpYy13ZWJydGNAdzMub3JnPg0KPj5TdWJqZWN0OiBS ZTogW3J0Y3dlYl0gU2luZ2xlIG9mZmVyIHdpdGggbXVsdGlwbGUgYW5zd2VyIGhhbmRsaW5nIGlu DQo+PkpTRVAgW3dhcyBSRTogTmV3IEpTRVAgZHJhZnQgcG9zdGVkXQ0KPj4NCj4+DQo+PkknbSBh IGJpdCBsb3N0IG9uIHVzZSBjYXNlIGluIFNJUCBjb250ZXh0IC0gYXNzdW1pbmcgdGhhdCB0aGUg VUFDIGRpZA0KPj5ub3QgZm9yayBidXQgdGhhdCBhIHByb3h5IG9yIEIyQlVBIGRpZCB0aGUgZm9y a2luZywgaXQgc2VlbXMgbGlrZSB0aGUNCj4+VUFDIHNob3VsZCBuZXZlciByZWNlaXZlIG1vcmUg dGhhbiBvbmUgZmluYWwgcmVzcG9uc2UuDQo+Pg0KPj5JbiB0aGUgY2FzZSBvZiBtb3ZpbmcgZnJv bSBkZXNrdG9wIHRvIG1vYmlsZSwgaXQgc2VlbXMgbGlrZSB0aGF0IGlzDQo+PnVwZGF0aW5nIHRo ZSBzdHJlYW0gYW5kIHdvdWxkIHVzZSBhIGNhbGwgZmxvdyBtb3JlIGxpa2UgdXBkYXRlIGV4YW1w bGVzDQo+PmluIHRoZSBkcmFmdCBpbnN0ZWFkIG9mIHRyeWluZyB0byByZXVzZSBzb21lIG9sZCBh bnN3ZXIuDQo+Pg0KPj4NCj4+T24gRmViIDE0LCAyMDEyLCBhdCAxMToyNCAsIFJhdmluZHJhbiwg UGFydGhhc2FyYXRoaSB3cm90ZToNCj4+DQo+Pj4gSnVzdGluLA0KPj4+DQo+Pj4gU29tZSBvZiB0 aGUgdXNlY2FzZXMgY291bGQgYmUNCj4+PiAxKSAgICAgIFRoZSBzYW1lIHVzZXIgb2YgYSB3ZWJz aXRlIHNpZ25lZC1pbiBpbiB0aGUgbXVsdGlwbGVzIGRldmljZXMNCj4+YW5kIGFjdHMgYXMgYW5z d2VyZXIsICB0aGUgc2Vzc2lvbiBlc3RhYmxpc2htZW50IHJlcXVlc3QgdG8gdGhlDQo+PmlkZW50 aXR5IHdpbGwgYWxlcnQgYWxsIHRoZSBzaWduZWQtaW4gZGV2aWNlcyBhbmQgaXQgaXMgcG9zc2li bGUgdGhhdA0KPj5tdWx0aXBsZSBkZXZpY2VzIGFuc3dlciB0byB0aGUgc2Vzc2lvbi4gSGVyZSwg dXNlciBtYXkgbW92ZSBmcm9tIG9uZQ0KPj5kZXZpY2UNCj4+KG1vYmlsZSkgdG8gYW5vdGhlciBk ZXZpY2UgKGRlc2t0b3ApIHdpdGhpbiB0aGUgc2Vzc2lvbiBhbmQgd2lzaGVzIHRvDQo+PmNvbnRp bnVlIHRoZSBzZXNzaW9uIHdpdGggdGhlIGxhc3QgYW5zd2VyLiBQbGVhc2Ugbm90ZSB0aGF0IHdl YnNpdGUgaXMNCj4+ZmxleGlibGUgdG8gcHJvdmlkZSB0aGlzIHNlcnZpY2UuDQo+Pj4gMikgICAg ICBSRkMgMzI2MSBTSVAgVUEgb2ZmZXIvYW5zd2VyIGhhbmRsaW5nIHcuci50IElOVklURSB3aXRo IFNEUA0KPnRvDQo+Pm11bHRpcGxlIDJ4eCB3aXRoIFNEUCBoYW5kbGluZyBzY2VuYXJpbyB1c2lu ZyBKU0VQDQo+Pj4gMykgICAgICBBbm90aGVyIFNJUCB1c2VjYXNlIGNvdWxkIGJlIG11bHRpcGxl IDE4eCByZXNwb25zZXMgd2l0aCBTRFANCj4+Zm9yIElOVklURSB3aXRoIFNEUCBhbmQgbXVsdGlw bGUgMnh4IHJlc3BvbnNlcyB3aXRob3V0IFNEUCBidXQgb3JkZXINCj4+d2l0aGluIDE4eCBhbmQg MjAwIGFyZSBub3Qgc2FtZS4gU2F5IDJ4eCBvZiB0aGUgc2Vjb25kIDE4eCBpcyByZWNlaXZlZA0K Pj5hcyB0aGUgZmlyc3QgMnh4LiBIZXJlLCB3ZSBuZWVkIHRvIGtub3cgaG93IHNlY29uZCAxOHgg aXMgaGFuZGxlZCBhbmQNCj4+YWxzbywgdGhlIHN1YnNlcXVlbnQgMnh4IGlzIGhhbmRsZWQuDQo+ Pj4NCj4+PiBPZiBjb3Vyc2UsIGl0IGlzIHBvc3NpYmxlIHRvIGJ1aWxkIG1vcmUgdXNlY2FzZXMg YXJvdW5kIHRoaXMgYXJlYS4gQXMNCj4+d2UgbWFkZSBzaWduYWxpbmcgb3V0c2lkZSB0aGUgc2Nv cGUgb2YgV2ViUlRDLCBpdCBpcyB1cHRvIEpTDQo+PmFwcGxpY2F0aW9uIHRvIGRlY2lkZSB0aGUg b3JkZXIgaW4gd2hpY2ggb2ZmZXIvYW5zd2VyIGhhcHBlbnMuIEknbSBub3QNCj4+cmVsYXRpbmcg b2ZmZXIvYW5zd2VyIEZTTSB3aXRoIHNlc3Npb24gZXN0YWJsaXNobWVudCBzdGF0ZSBsaWtlIDE4 eCwNCj4+Mnh4IGJ1dCBJJ20gaW50ZXJlc3RlZCBpbiBrbm93aW5nIGJyb3dzZXIgbWVkaWEgcGxh bmUgYmVoYXZpb3IgaW4NCj4+ZGlmZmVyZW50IHN0YXRlIG9mIG9mZmVyL2Fuc3dlciBoYW5kbGlu ZyBieSB3aGljaCBKUyBhcHBsaWNhdGlvbg0KPj5iZWhhdmVzIGNvbnNpc3RlbnRseSBpbiBhbGwg YnJvd3NlcnMuDQo+Pj4NCj4+PiBUaGFua3MNCj4+PiBQYXJ0aGENCj4+Pg0KPj4+DQo+Pj4gRnJv bTogSnVzdGluIFViZXJ0aSBbbWFpbHRvOmp1YmVydGlAZ29vZ2xlLmNvbTxtYWlsdG86anViZXJ0 aUBnb29nbGUuY29tPl0NCj4+PiBTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAxNCwgMjAxMiAxMToz NiBQTQ0KPj4+IFRvOiBSYXZpbmRyYW4sIFBhcnRoYXNhcmF0aGkNCj4+PiBDYzogcnRjd2ViQGll dGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+OyBwdWJsaWMtd2VicnRjQHczLm9yZzxtYWls dG86cHVibGljLXdlYnJ0Y0B3My5vcmc+DQo+Pj4gU3ViamVjdDogUmU6IFNpbmdsZSBvZmZlciB3 aXRoIG11bHRpcGxlIGFuc3dlciBoYW5kbGluZyBpbiBKU0VQIFt3YXMNCj4+UkU6IFtydGN3ZWJd IE5ldyBKU0VQIGRyYWZ0IHBvc3RlZF0NCj4+Pg0KPj4+IFBhcnRoYSwNCj4+Pg0KPj4+IEkgbmVl ZCBtb3JlIGluZm9ybWF0aW9uIGFib3V0IHRoZSB1c2UgY2FzZSB0byBwcm92aWRlIGFuIGFjY3Vy YXRlDQo+PnJlc3BvbnNlLiBBcyBtZW50aW9uZWQgaW4gbXkgZWFybGllciBtYWlsLCBhcmUgYm90 aCBhbnN3ZXJzIDJ4eA0KPj5yZXNwb25zZXM/DQo+Pj4NCj4+PiBPbiBUdWUsIEZlYiAxNCwgMjAx MiBhdCAxMjoxNyBQTSwgUmF2aW5kcmFuLCBQYXJ0aGFzYXJhdGhpDQo+PjxwcmF2aW5kcmFuQHNv bnVzbmV0LmNvbTxtYWlsdG86cHJhdmluZHJhbkBzb251c25ldC5jb20+PiB3cm90ZToNCj4+PiBI aSBKdXN0aW4sDQo+Pj4NCj4+PiBJbiB0aGlzIG1haWwgdGhyZWFkLCBMZXQgdXMgZGVmaW5lIHRo ZSBiZWhhdmlvciBvZiBtdWx0aXBsZSAoYXRsZWFzdA0KPj50d28pIGFuc3dlcnMgZm9yIHRoZSBz aW5nbGUgb2ZmZXIgaW4gV2ViUlRDIGJyb3dzZXIuICBOb3csIFBsZWFzZSBsZXQNCj4+bWUga25v dyB5b3VyIG9waW5pb24gZm9yIG15IGJlbG93IG1haWwuDQo+Pj4NCj4+PiBUaGFua3MNCj4+PiBQ YXJ0aGENCj4+Pg0KPj4+IEZyb206IEp1c3RpbiBVYmVydGkgW21haWx0bzpqdWJlcnRpQGdvb2ds ZS5jb208bWFpbHRvOmp1YmVydGlAZ29vZ2xlLmNvbT5dDQo+Pj4gU2VudDogVHVlc2RheSwgRmVi cnVhcnkgMTQsIDIwMTIgOTo0NyBQTQ0KPj4+DQo+Pj4gVG86IFJhdmluZHJhbiwgUGFydGhhc2Fy YXRoaQ0KPj4+IENjOiBydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz47IHB1 YmxpYy13ZWJydGNAdzMub3JnPG1haWx0bzpwdWJsaWMtd2VicnRjQHczLm9yZz4NCj4+PiBTdWJq ZWN0OiBSZTogU2luZ2xlIG9mZmVyIHdpdGggbXVsdGlwbGUgYW5zd2VyIGhhbmRsaW5nIGluIEpT RVAgW3dhcw0KPj5SRTogW3J0Y3dlYl0gTmV3IEpTRVAgZHJhZnQgcG9zdGVkXQ0KPj4+DQo+Pj4N Cj4+Pg0KPj4+IE9uIFR1ZSwgRmViIDE0LCAyMDEyIGF0IDY6MzkgQU0sIFJhdmluZHJhbiwgUGFy dGhhc2FyYXRoaQ0KPj48cHJhdmluZHJhbkBzb251c25ldC5jb208bWFpbHRvOnByYXZpbmRyYW5A c29udXNuZXQuY29tPj4gd3JvdGU6DQo+Pj4gSGkgSnVzdGluLA0KPj4+DQo+Pj4gSXQgd2lsbCBi ZSBnb29kIHRvIG1lbnRpb24gaW4gdGhlIEpTRVAgZHJhZnQgIHRoYXQgbXVsdGlwbGUgYW5zd2Vy cw0KPj5mb3Igc2luZ2xlIG9mZmVyIHdpbGwgbm90IGxlYWQgdG8gUlRQIE1peGluZyBhbmQgV2Vi UlRDIGNsaWVudCBhY3RzIGFzDQo+PlJUUCBFbmRwb2ludC4NCj4+Pg0KPj4+IEZhaWxpbmcgdGhl IHNlY29uZCBBbnN3ZXIgd2lsbCBiZSBsaW1pdGluZyB0aGUgcHJvdmlzaW9uIGluIFJGQyAzMjY0 DQo+Pm9mZmVyL2Fuc3dlciBpdHNlbGYgYXMgUkZDIDMyNjQgc3VwcG9ydHMgc2luZ2xlIG9mZmVy IHdpdGggbXVsdGlwbGUNCj4+YW5zd2VyLiBBbHNvLCBpdCBpcyBiZXR0ZXIgdG8gZGVmaW5lIHRo ZSBiZWhhdmlvciBpbiBBUEkgcmF0aGVyIHRoYW4NCj4+cHV0dGluZyB0aGlzIHNjZW5hcmlvIGlu IHRoZSBicm93c2VyIGltcGxlbWVudGF0aW9uIHNwZWNpZmljLiBJbiBzaW1wbGUNCj4+c2NlbmFy aW9zIChsaWtlIGFsZXJ0aW5nIHdpdGggb25lIGFuc3dlciwgY29ubmVjdCB3aXRoIHNlY29uZCBh bnN3ZXIpLA0KPj5yZXBsYWNpbmcgdGhlIHByZXZpb3VzIEFOU1dFUiB3aWxsIGJlIGV4cGVjdGVk IGJlaGF2aW9yLiBUaGlzIG1heSBub3QNCj4+YmUgZGVzaXJlZCBiZWhhdmlvciBpbiBjYXNlIHR3 byBjb25uZWN0IHJlc3BvbnNlcyBmcm9tIGRpZmZlcmVudCBXZWJSVEMNCj4+Y2xpZW50cyByZWNl aXZlZCB3aXRoIGRpZmZlcmVudCBhbnN3ZXJzICBidXQgdGhlcmUgaXMgbm8gb3RoZXINCj4+YWx0 ZXJuYXRpdmUgc29sdXRpb24gcG9zc2libGUgd2l0aG91dCBtaXhpbmcuDQo+Pj4NCj4+PiBEbyB5 b3UgbmVlZCB0byBzdXBwb3J0IDIgZmluYWwgYW5zd2Vycywgb3Igd291bGQgdGhlIHByb3Zpc2lv bmFsDQo+PmFuc3dlciBzdXBwb3J0IHByb3ZpZGVkIHZpYSBTRFBfUFJBTlNXRVIgd29yayBmb3Ig eW91Pw0KPj4+DQo+Pj4gSU1PLCBpdCBpcyBiZXR0ZXIgdG8gZGVmaW5lIGl0IGV4cGxpY2l0bHkg aW4gSlNFUCB0aGF0ICJsYXRlc3QgQU5TV0VSDQo+PnRvIHRoZSBvZmZlciB3aWxsIHJlcGxhY2Ug dGhlIGV4aXN0aW5nIGFuc3dlciBpcyB0aGUgZXhwZWN0ZWQgYmVoYXZpb3INCj4+Ii4gQWxzbywg UGxlYXNlIG1lbnRpb25lZCB0aGF0IEpTIGFwcGxpY2F0aW9uIGlzIHJlc3BvbnNpYmxlIGZvcg0K Pj5kaXNjYXJkaW5nICh0ZXJtaW5hdGluZykgcHJldmlvdXMgQU5TV0VSIG5vdGlmaWNhdGlvbi4g ICBQbGVhc2UgbGV0IG1lDQo+PnlvdXIgb3BpbmlvbiBvbiB0aGlzIGNsb3N1cmUuDQo+Pj4NCj4+ PiBUaGFua3MNCj4+PiBQYXJ0aGENCj4+Pg0KPj4+IEZyb206IEp1c3RpbiBVYmVydGkgW21haWx0 bzpqdWJlcnRpQGdvb2dsZS5jb208bWFpbHRvOmp1YmVydGlAZ29vZ2xlLmNvbT5dDQo+Pj4gU2Vu dDogVHVlc2RheSwgRmVicnVhcnkgMTQsIDIwMTIgNzoyOSBQTQ0KPj4+IFRvOiBSYXZpbmRyYW4s IFBhcnRoYXNhcmF0aGkNCj4+PiBDYzogcnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0 Zi5vcmc+OyBwdWJsaWMtd2VicnRjQHczLm9yZzxtYWlsdG86cHVibGljLXdlYnJ0Y0B3My5vcmc+ DQo+Pj4gU3ViamVjdDogUmU6IFNpbmdsZSBvZmZlciB3aXRoIG11bHRpcGxlIGFuc3dlciBoYW5k bGluZyBpbiBKU0VQIFt3YXMNCj4+UkU6IFtydGN3ZWJdIE5ldyBKU0VQIGRyYWZ0IHBvc3RlZF0N Cj4+Pg0KPj4+IFJlZ2FyZGluZyB5b3VyIHByZXZpb3VzIG1haWwsIGFuIEFOU1dFUiBhZnRlciBh biBBTlNXRVIgd291bGQgZWl0aGVyDQo+PmZhaWwgKGlmIHdlIHdhbnRlZCB0byBzaW1wbGlmeSks IG9yIHJlcGxhY2UgdGhlIHByZXZpb3VzIEFOU1dFUg0KPj4oZXNzZW50aWFsbHkgdGhlIHNhbWUg YXMgaWYgeW91IGhhZCBkb25lIHNldExvY2FsRGVzY3JpcHRpb24oT0ZGRVIsDQo+PmxvY2FsRGVz Y3JpcHRpb24pIGZvbGxvd2VkIGJ5IHNldFJlbW90ZURlc2NyaXB0aW9uKEFOU1dFUiwgYW5zd2Vy MikuDQo+Pj4NCj4+PiBJbiBubyBjYXNlIHdvdWxkIGl0IG1peCB0aGUgZGVzY3JpcHRpb25zL21l ZGlhIGZyb20gYm90aCBhbnN3ZXJzLg0KPj4+DQo+Pj4gT3RoZXIgY29tbWVudHMgaW5saW5lIGJl bG93Lg0KPj4+DQo+Pj4gT24gVHVlLCBGZWIgMTQsIDIwMTIgYXQgMToyNCBBTSwgUmF2aW5kcmFu LCBQYXJ0aGFzYXJhdGhpDQo+PjxwcmF2aW5kcmFuQHNvbnVzbmV0LmNvbTxtYWlsdG86cHJhdmlu ZHJhbkBzb251c25ldC5jb20+PiB3cm90ZToNCj4+PiBIaSBKdXN0aW4sDQo+Pj4NCj4+PiBBZGRp bmcgdG8gbXkgZWFybGllciBtYWlsLCBJbiBjYXNlIGFuc3dlcjIgU0RQIGlzIHVwZGF0ZWQgaW4g b2ZmZXJlcjENCj4+YnJvd3NlciB3aXRob3V0IG5vdGlmeWluZyBhbnN3ZXJlcjEsIHRoZW4gYW5z d2VyMSB3aWxsIGNvbnRpbnVlIHRvDQo+PnRyYW5zbWl0IFJUUCB3aGljaCBtYXkgbm90IGJlIGRl c2lyZWQgYmVoYXZpb3IuIElNTywgd2UgbmVlZCB0byBkZWZpbmUNCj4+dGhpcyBiZWhhdmlvciBj bGVhcmx5IGluIG9mZmVyZXIgc2lkZS4gU29tZSBvZiB0aGUgcG9zc2libGUgc29sdXRpb25zDQo+ PmFyZQ0KPj4+DQo+Pj4gMSkgICAgICBvZmZlcmVyMSBoYXMgdG8gc2VuZCBhdGxlYXN0IFJUQ1Ag QllFIHBhY2tldHMgdG93YXJkcw0KPj5hbnN3ZXJlcjEgd2hpbGUgYWNjZXB0aW5nIHRoZSBhbnN3 ZXJlcjIgU0RQLg0KPj4+DQo+Pj4gMikgICAgICBUaHJvdyBjYWxsYmFjayB0byBjbGVhciBhbnN3 ZXIxIFNEUCB0b3dhcmRzIG9mZmVyZXJKUy4NCj4+Pg0KPj4+DQo+Pj4gVGhlIGFwcGxpY2F0aW9u IHdoaWNoIGNhbGxlZCBzZXRSZW1vdGVEZXNjcmlwdGlvbiB0d2ljZSBzaG91bGQgaGF2ZQ0KPj50 aGUgYmVzdCBpZGVhIGFib3V0IHdoYXQgaXMgZ29pbmcgb24sIGFuZCB0aGVyZWZvcmUgaXMgcmVz cG9uc2libGUgZm9yDQo+Pm5vdGlmeWluZyBhbnN3ZXJlcjEgdGhhdCBpdHMgYW5zd2VyIGhhcyBi ZWVuIGRpc2NhcmRlZCwgaWYgaXQgbWFrZXMNCj4+c2Vuc2UgdG8gZG8gc28uIE5vIGNhbGxiYWNr IHNob3VsZCBiZSBuZWVkZWQgaGVyZS4NCj4+Pg0KPj4+DQo+Pj4gUGxlYXNlIGxldCBtZSBrbm93 IHlvdXIgb3BpbmlvbiBoZXJlLg0KPj4+DQo+Pj4gVGhhbmtzDQo+Pj4gUGFydGhhDQo+Pj4NCj4+ PiBGcm9tOiBSYXZpbmRyYW4sIFBhcnRoYXNhcmF0aGkNCj4+PiBTZW50OiBUdWVzZGF5LCBGZWJy dWFyeSAxNCwgMjAxMiAxMjowNyBBTQ0KPj4+IFRvOiAnSnVzdGluIFViZXJ0aSc7IHJ0Y3dlYkBp ZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPjsgcHVibGljLXdlYnJ0Y0B3My5vcmc8bWFp bHRvOnB1YmxpYy13ZWJydGNAdzMub3JnPg0KPj4+IFN1YmplY3Q6IFNpbmdsZSBvZmZlciB3aXRo IG11bHRpcGxlIGFuc3dlciBoYW5kbGluZyBpbiBKU0VQIFt3YXMgUkU6DQo+PltydGN3ZWJdIE5l dyBKU0VQIGRyYWZ0IHBvc3RlZF0NCj4+Pg0KPj4+IEhpIEp1c3RpbiwNCj4+Pg0KPj4+IEluIHRo ZSBkcmFmdCwgaXQgaXMgbm90IHNwZWxsZWQgb3V0IGV4cGxpY2l0bHkgd2hhdCBpcyB0aGUgZXhw ZWN0ZWQNCj4+YmVoYXZpb3IgaW4gb2ZmZXJlciBicm93c2VyIGluIGNhc2UgbXVsdGlwbGUgYW5z d2VyIGlzIHJlY2VpdmVkIGZvcg0KPj5zaW5nbGUgb2ZmZXIuIE9mZmVyL2Fuc3dlciBleGNoYW5n ZSBpbiBvZmZlcmVyIGlzIGFzIGZvbGxvd3M6DQo+Pj4NCj4+PiBPZmZlcmVySlMtPk9mZmVyZXJV QTogdmFyIG9mZmVyID0gcGMuY3JlYXRlT2ZmZXIobnVsbCk7DQo+Pj4gT2ZmZXJlckpTLT5PZmZl cmVyVUE6IHBjLnNldExvY2FsRGVzY3JpcHRpb24oU0RQX09GRkVSLCBvZmZlcik7DQo+Pj4gT2Zm ZXJlckpTLT5PZmZlcmVyVUE6ICBwYy5zZXRSZW1vdGVEZXNjcmlwdGlvbihTRFBfQU5TV0VSLCBh bnN3ZXIxKTsNCj4+PiBPZmZlcmVyVUEtPkFuc3dlcmVyMVVBOiA8bWVkaWE+DQo+Pj4gT2ZmZXJl ckpTLT5PZmZlcmVyVUE6ICBwYy5zZXRSZW1vdGVEZXNjcmlwdGlvbihTRFBfQU5TV0VSLCBhbnN3 ZXIyKTsNCj4+PiBPZmZlcmVyVUEtPkFuc3dlcmVyP1VBOiA8bWVkaWE+Pw0KPj4+DQo+Pj4gTXkg dW5kZXJzdGFuZGluZyBpcyB0aGF0ICJhbnN3ZXIyIiB3aWxsIHVwZGF0ZSAiYW5zd2VyMSIgaW4g YnJvd3Nlcg0KPj5hbmQgc3RhcnRpbmcgc2VuZGluZy9yZWNlaXZpbmcgbWVkaWEgdG93YXJkcyBh bnN3ZXIyIG1lZGlhIElQIGFuZCBwb3J0Lg0KPj5Db3VsZCB5b3UgcGxlYXNlIGV4cGxhaW4gdGhl IGV4cGVjdGVkIGJlaGF2aW9yIGluIG9mZmVyZXIgYnJvd3Nlcg0KPj53aGV0aGVyIGl0IHVwZGF0 ZXMgdGhlIG1lZGlhIHN0cmVhbSBiYXNlZCBvbiB0aGUgbGFzdCBhbnN3ZXIgb3IgbWl4ZXMNCj4+ Ym90aCBhbnN3ZXJlci4NCj4+Pg0KPj4+IFRoYW5rcw0KPj4+IFBhcnRoYQ0KPj4+DQo+Pj4gRnJv bTogcnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3Jn PiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpydGN3ZWItYm91bmNlc0Bp ZXRmLm9yZz5dIE9uDQo+PkJlaGFsZiBPZiBKdXN0aW4gVWJlcnRpDQo+Pj4gU2VudDogVGh1cnNk YXksIEZlYnJ1YXJ5IDA5LCAyMDEyIDI6MjcgQU0NCj4+PiBUbzogcnRjd2ViQGlldGYub3JnPG1h aWx0bzpydGN3ZWJAaWV0Zi5vcmc+OyBwdWJsaWMtd2VicnRjQHczLm9yZzxtYWlsdG86cHVibGlj LXdlYnJ0Y0B3My5vcmc+DQo+Pj4gU3ViamVjdDogW3J0Y3dlYl0gTmV3IEpTRVAgZHJhZnQgcG9z dGVkDQo+Pj4NCj4+PiBOb3cgYXZhaWxhYmxlIGF0IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJh ZnQtdWJlcnRpLXJ0Y3dlYi1qc2VwLQ0KPj4wMS50eHQNCj4+Pg0KPj4+IEluY2x1ZGVzIGNoYW5n ZXMgYmFzZWQgb24gaW1wbGVtZW50YXRpb24gZmVlZGJhY2ssIGFuZCBJIGJlbGlldmUgaXQNCj4+ YWRkcmVzc2VzIG1vc3Qgb2YgdGhlIGNvbmNlcm5zIHJhaXNlZCBpbiBsYXN0IHdlZWsncyBpbnRl cmltIG1lZXRpbmdzOg0KPj4+IC0gSW5pdGlhbCBkb2N1bWVudGF0aW9uIHByb3ZpZGVkIGZvciBl YWNoIEFQSSBjYWxsLCBhbmQgd2hhdCBzdGF0ZQ0KPj5jaGFuZ2VzIGl0IGNhdXNlcw0KPj4+IC0g TW9yZSBleGFtcGxlcywgaW5jbHVkaW5nIGEgY29tcGxldGUgYmFzaWMgc2FtcGxlIGFwcGxpY2F0 aW9uDQo+Pj4gLSBTaW1wbGlmaWVkIGFwcHJvYWNoIHRvIHRyaWNrbGUgY2FuZGlkYXRlIGhhbmRs aW5nDQo+Pj4gLSBSZXNvbHZlZCBjb25jZXJucyBhYm91dCBob3cgdG8gc2VwYXJhdGUgU0RQIGF0 dHJpYnV0ZXMgaW50byBtZWRpYSAvDQo+PnRyYW5zcG9ydA0KPj4+IC0gUHJvdmlkZWQgZW5jYXBz dWxhdGlvbiBmb3IgU0RQIGJsb2JzIGFuZCBJQ0UgY2FuZGlkYXRlIGxpbmVzLCBpbg0KPj4+IHRo ZQ0KPj5ldmVudCB3ZSB3YW50IHRvIGNoYW5nZSBlbmNvZGluZ3Mgb3IgcHJvdmlkZSBoZWxwZXIg ZnVuY3Rpb25zIGZvciBKUw0KPj4+IC0gUHJvdmlkZWQgbWVjaGFuaXNtIGZvciBsaW1pdGluZyBj YW5kaWRhdGVzIHRvIFRVUk4tb25seQ0KPj4+IC0gUmVzb2x2ZWQgc2V2ZXJhbCBpbXBsZW1lbnRh dGlvbiBpc3N1ZXMNCj4+Pg0KPj4+IEkgaGF2ZSBub3QgeWV0IGFkZHJlc3NlZCB0aGUgbm9uLW92 ZXJsYXBwaW5nIGNvZGVjIGNvbmNlcm4gbWVudGlvbmVkDQo+PmluIHRoZSBpbnRlcmltIG1lZXRp bmcuIEkgdGhpbmsgdGhlcmUgYXJlIHdheXMgb2YgaGFuZGxpbmcgdGhpcyBlaXRoZXINCj4+aW4g dGhlIGFwcGxpY2F0aW9uIG9yIHRoZSBpbXBsZW1lbnRhdGlvbiwgYnV0IEkgd2FudGVkIHRvIGdl dCB0aGlzIC0wMQ0KPj5vdXQgZmlyc3QgZm9yIGZlZWRiYWNrLg0KPj4+DQo+Pj4NCj4+Pg0KPj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gcnRj d2ViIG1haWxpbmcgbGlzdA0KPj4+IHJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYu b3JnPg0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQoN Cg== --_000_387F9047F55E8C42850AD6B3A7A03C6C0E0406FAinbamail01sonus_ 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 Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkhpIEp1c3Rpbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoaXMgc291bmRzIGdvb2QgdG8gbWUuIEnigJlsbCBz ZW5kIHRoZSBleGFtcGxlIGNhbGxmbG93IEFTQVAuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3M8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+UGFydGhhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+IEp1c3RpbiBVYmVydGkgW21haWx0bzpqdWJlcnRpQGdvb2dsZS5jb21d DQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBGZWJydWFyeSAxNywgMjAxMiA4OjA2IEFNPGJy Pg0KPGI+VG86PC9iPiBSYXZpbmRyYW4sIFBhcnRoYXNhcmF0aGk8YnI+DQo8Yj5DYzo8L2I+IEN1 bGxlbiBKZW5uaW5nczsgcnRjd2ViQGlldGYub3JnOyBwdWJsaWMtd2VicnRjQHczLm9yZzxicj4N CjxiPlN1YmplY3Q6PC9iPiBSZTogW3J0Y3dlYl0gU2luZ2xlIG9mZmVyIHdpdGggbXVsdGlwbGUg YW5zd2VyIGhhbmRsaW5nIGluIEpTRVAgW3dhcyBSRTogTmV3IEpTRVAgZHJhZnQgcG9zdGVkXTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFncmVlIGl0IGhh cyBub3QgYmVlbiBhZGRyZXNzZWQuIEknbSBoYXZpbmcgc29tZSB0cm91YmxlIHVuZGVyc3RhbmRp bmcgdGhlIGV4YWN0IGZsb3dzIHRoYXQgd2UgbmVlZCB0byBhZGRyZXNzIGhlcmUgKG11bHRpcGxl IDJ4eCwgbXVsdGlwbGUgMTh4IGZvbGxvd2VkIGJ5IDJ4eCwgbXVsdGlwbGUgMTh4IGZvbGxvd2Vk IGJ5IG11bHRpcGxlIDJ4eCkgYnV0IGlmIEkgdW5kZXJzdGFuZCBjb3JyZWN0bHkgeW91ciBzdWdn ZXN0aW9uDQogd2FzOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+MSkgYWxsb3cgYSBzZXRSZW1vdGVEZXNjKFNEUF9BTlNXRVIpIHRvIGZvbGxvdyBhIHNldFJl bW90ZURlc2MoU0RQX0FOU1dFUik8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjIpIGRvY3VtZW50IHRoYXQgaW4gdGhpcyBjYXNlIChtdWx0aXBsZSAy eHgpLCB0aGUgSlMgaXMgcmVzcG9uc2libGUgZm9yIHNlbmRpbmcgQllFIHRvIHRoZSBwcmV2aW91 cyBhbnN3ZXJlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+d2hpY2ggc291bmRzIHRvdGFsbHkgcmVhc29uYWJsZSB0byBtZS4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgdGhp cyBzb3VuZHMgZ29vZCB0byB5b3UsIHdvdWxkIHlvdSBtaW5kIHNrZXRjaGluZyBvdXQgYSBjYWxs IGZsb3cgdGhhdCBJIGNvdWxkIGluY2x1ZGUgaW4gdGhlIGV4YW1wbGVzIHNlY3Rpb24/PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEZlYiAxNiwg MjAxMiBhdCAyOjExIEFNLCBSYXZpbmRyYW4sIFBhcnRoYXNhcmF0aGkgJmx0OzxhIGhyZWY9Im1h aWx0bzpwcmF2aW5kcmFuQHNvbnVzbmV0LmNvbSI+cHJhdmluZHJhbkBzb251c25ldC5jb208L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkN1bGxlbi9K dXN0aW4sPGJyPg0KPGJyPg0KU2luZ2xlIG9mZmVyIHdpdGggbXVsdGlwbGUgYW5zd2VyIG9wZW4g aXRlbSBpcyBub3QgYWRkcmVzc2VkIGluIC0wMiB2ZXJzaW9uIG9mIEpTRVAgZHJhZnQuIEhvcGUg eW91IGZpcnN0IGFncmVlIHRoaXMgYXMgYW4gb3BlbiBpdGVtIGluIEpTRVAuPGJyPg0KPGJyPg0K VGhhbmtzPGJyPg0KUGFydGhhPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxicj4NCiZndDstLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZn dDtGcm9tOiBSYXZpbmRyYW4sIFBhcnRoYXNhcmF0aGk8YnI+DQomZ3Q7U2VudDogV2VkbmVzZGF5 LCBGZWJydWFyeSAxNSwgMjAxMiAyOjQzIFBNPGJyPg0KJmd0O1RvOiAnQ3VsbGVuIEplbm5pbmdz Jzxicj4NCiZndDtDYzogSnVzdGluIFViZXJ0aTsgPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRm Lm9yZyI+cnRjd2ViQGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOnB1YmxpYy13ZWJydGNA dzMub3JnIj4NCnB1YmxpYy13ZWJydGNAdzMub3JnPC9hPjxicj4NCiZndDtTdWJqZWN0OiBSRTog W3J0Y3dlYl0gU2luZ2xlIG9mZmVyIHdpdGggbXVsdGlwbGUgYW5zd2VyIGhhbmRsaW5nIGluIEpT RVA8YnI+DQomZ3Q7W3dhcyBSRTogTmV3IEpTRVAgZHJhZnQgcG9zdGVkXTxicj4NCiZndDs8YnI+ DQomZ3Q7Q3VsbGVuLDxicj4NCiZndDs8YnI+DQomZ3Q7UkZDMzI2MSByZWZlcmVuY2VzIGZvciBy ZWNlaXZpbmcgbXVsdGlwbGUgMnh4IGluIFVBQyB3aGljaCBkb2VzIG5vdCBmb3JrPGJyPg0KJmd0 O0lOVklURSBhcmUgYXMgZm9sbG93czo8YnI+DQomZ3Q7PGJyPg0KJmd0OyZsdDtSRkMgcXVvdGUm Z3Q7PGJyPg0KJmd0O1NlYyAxMy4xIFBhcmEgMzo8YnI+DQomZ3Q7PGJyPg0KJmd0O1RoZXJlZm9y ZSwgd2hlbiBtdWx0aXBsZSAyeHggcmVzcG9uc2VzIGFyZSByZWNlaXZlZCBmcm9tIGRpZmZlcmVu dDxicj4NCiZndDtyZW1vdGUgVUFzIChiZWNhdXNlIHRoZSBJTlZJVEUgZm9ya2VkKSwgZWFjaCAy eHggZXN0YWJsaXNoZXMgYSBkaWZmZXJlbnQ8YnI+DQomZ3Q7ZGlhbG9nLiAmbmJzcDtBbGwgdGhl c2UgZGlhbG9ncyBhcmUgcGFydCBvZiB0aGUgc2FtZSBjYWxsLjxicj4NCiZndDs8YnI+DQomZ3Q7 U2VjIDEzLjIuMi40IDJ4eCBSZXNwb25zZXM8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmbmJzcDsgTXVs dGlwbGUgMnh4IHJlc3BvbnNlcyBtYXkgYXJyaXZlIGF0IHRoZSBVQUMgZm9yIGEgc2luZ2xlIElO VklURTxicj4NCiZndDsgJm5ic3A7IHJlcXVlc3QgZHVlIHRvIGEgZm9ya2luZyBwcm94eS4gJm5i c3A7RWFjaCByZXNwb25zZSBpcyBkaXN0aW5ndWlzaGVkIGJ5PGJyPg0KJmd0OyAmbmJzcDsgdGhl IHRhZyBwYXJhbWV0ZXIgaW4gdGhlIFRvIGhlYWRlciBmaWVsZCwgYW5kIGVhY2ggcmVwcmVzZW50 cyBhPGJyPg0KJmd0OyAmbmJzcDsgZGlzdGluY3QgZGlhbG9nLCB3aXRoIGEgZGlzdGluY3QgZGlh bG9nIGlkZW50aWZpZXIuPGJyPg0KJmd0Ozxicj4NCiZndDsgJm5ic3A7IElmLCBhZnRlciBhY2tu b3dsZWRnaW5nIGFueSAyeHggcmVzcG9uc2UgdG8gYW4gSU5WSVRFLCB0aGUgVUFDIGRvZXM8YnI+ DQomZ3Q7ICZuYnNwOyBub3Qgd2FudCB0byBjb250aW51ZSB3aXRoIHRoYXQgZGlhbG9nLCB0aGVu IHRoZSBVQUMgTVVTVCB0ZXJtaW5hdGU8YnI+DQomZ3Q7ICZuYnNwOyB0aGUgZGlhbG9nIGJ5IHNl bmRpbmcgYSBCWUUgcmVxdWVzdCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiAxNS48YnI+DQomZ3Q7 Jmx0Oy9SRkMgcXVvdGUmZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDtBcyBwZXIgdGhlIGxhc3Qgc3Rh dGVtZW50cywgaXQgaXMgdXB0byB0aGUgU0lQIGFwcGxpY2F0aW9uIHRvIGRlY2lkZTxicj4NCiZn dDt3aGljaCBvbmUgb2YgdGhlIGZpbmFsIDJ4eCByZXNwb25zZSBoYXMgdG8gYmUgaW5jbHVkZWQg d2l0aGluIHRoZSBjYWxsLjxicj4NCiZndDtUaGUgdXNlY2FzZSAzIGlzIGJhc2VkIG9uIFJGQzMy NjIgKFBSQUNLKSBzdXBwb3J0IHdoZXJlaW4gaXQgaXMgcG9zc2libGU8YnI+DQomZ3Q7dG8gcmVj ZWl2ZSBtdWx0aXBsZSBmb3JrZWQgMTh4IHdpdGggU0RQIGZvbGxvd2VkIGJ5IDJ4eCB3aXRoIG9y IHdpdGhvdXQ8YnI+DQomZ3Q7U0RQIGFuZCBTSVAgMnh4IHJlc3BvbnNlIGlzIG5vdCB0aWVkIHRv IG9mZmVyL2Fuc3dlciBleGNoYW5nZS48YnI+DQomZ3Q7PGJyPg0KJmd0O0kgaGF2ZSBwcm92aWRl ZCBtb2JpbGUgdG8gZGVza3RvcCBhcyBhbiBleGFtcGxlIHRvIGp1c3RpZnkgdGhlIGxhc3Q8YnI+ DQomZ3Q7YW5zd2VyIG1heSBiZSB1c2VkIGluIHRoZSBvZmZlciBpbiBzb21lIEpTIGFwcGxpY2F0 aW9uLiBBcyBJIG1lbnRpb25lZDxicj4NCiZndDtiZWxvdywgdGhlcmUgaXMgbm8gbmVlZCB0byBy ZXN0cmljdCB1cGRhdGluZyBsYXRlc3QgYW5zd2VyIGZvciBhbiBvZmZlcjxicj4NCiZndDtpbiB0 ZXJtcyBvZiBBUEkgYW5kIHByb3RvY29sLjxicj4NCiZndDs8YnI+DQomZ3Q7VGhhbmtzPGJyPg0K Jmd0O1BhcnRoYTxicj4NCiZndDs8YnI+DQomZ3Q7Jmd0Oy0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tPGJyPg0KJmd0OyZndDtGcm9tOiBDdWxsZW4gSmVubmluZ3MgW21haWx0bzo8YSBocmVmPSJt YWlsdG86Zmx1ZmZ5QGlpaS5jYSI+Zmx1ZmZ5QGlpaS5jYTwvYT5dPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsmZ3Q7U2VudDog V2VkbmVzZGF5LCBGZWJydWFyeSAxNSwgMjAxMiAxOjMxIFBNPGJyPg0KJmd0OyZndDtUbzogUmF2 aW5kcmFuLCBQYXJ0aGFzYXJhdGhpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4mZ3Q7 Jmd0O0NjOiBKdXN0aW4gVWJlcnRpOyA8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIj4N CnJ0Y3dlYkBpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpwdWJsaWMtd2VicnRjQHczLm9y ZyI+cHVibGljLXdlYnJ0Y0B3My5vcmc8L2E+PGJyPg0KJmd0OyZndDtTdWJqZWN0OiBSZTogW3J0 Y3dlYl0gU2luZ2xlIG9mZmVyIHdpdGggbXVsdGlwbGUgYW5zd2VyIGhhbmRsaW5nIGluPGJyPg0K Jmd0OyZndDtKU0VQIFt3YXMgUkU6IE5ldyBKU0VQIGRyYWZ0IHBvc3RlZF08YnI+DQomZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDtJJ20gYSBiaXQgbG9zdCBvbiB1c2UgY2FzZSBp biBTSVAgY29udGV4dCAtIGFzc3VtaW5nIHRoYXQgdGhlIFVBQyBkaWQ8YnI+DQomZ3Q7Jmd0O25v dCBmb3JrIGJ1dCB0aGF0IGEgcHJveHkgb3IgQjJCVUEgZGlkIHRoZSBmb3JraW5nLCBpdCBzZWVt cyBsaWtlIHRoZTxicj4NCiZndDsmZ3Q7VUFDIHNob3VsZCBuZXZlciByZWNlaXZlIG1vcmUgdGhh biBvbmUgZmluYWwgcmVzcG9uc2UuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0O0luIHRoZSBj YXNlIG9mIG1vdmluZyBmcm9tIGRlc2t0b3AgdG8gbW9iaWxlLCBpdCBzZWVtcyBsaWtlIHRoYXQg aXM8YnI+DQomZ3Q7Jmd0O3VwZGF0aW5nIHRoZSBzdHJlYW0gYW5kIHdvdWxkIHVzZSBhIGNhbGwg ZmxvdyBtb3JlIGxpa2UgdXBkYXRlIGV4YW1wbGVzPGJyPg0KJmd0OyZndDtpbiB0aGUgZHJhZnQg aW5zdGVhZCBvZiB0cnlpbmcgdG8gcmV1c2Ugc29tZSBvbGQgYW5zd2VyLjxicj4NCiZndDsmZ3Q7 PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0O09uIEZlYiAxNCwgMjAxMiwgYXQgMTE6MjQgLCBS YXZpbmRyYW4sIFBhcnRoYXNhcmF0aGkgd3JvdGU6PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyZndDsgSnVzdGluLDxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBTb21lIG9m IHRoZSB1c2VjYXNlcyBjb3VsZCBiZTxicj4NCiZndDsmZ3Q7Jmd0OyAxKSAmbmJzcDsgJm5ic3A7 ICZuYnNwO1RoZSBzYW1lIHVzZXIgb2YgYSB3ZWJzaXRlIHNpZ25lZC1pbiBpbiB0aGUgbXVsdGlw bGVzIGRldmljZXM8YnI+DQomZ3Q7Jmd0O2FuZCBhY3RzIGFzIGFuc3dlcmVyLCAmbmJzcDt0aGUg c2Vzc2lvbiBlc3RhYmxpc2htZW50IHJlcXVlc3QgdG8gdGhlPGJyPg0KJmd0OyZndDtpZGVudGl0 eSB3aWxsIGFsZXJ0IGFsbCB0aGUgc2lnbmVkLWluIGRldmljZXMgYW5kIGl0IGlzIHBvc3NpYmxl IHRoYXQ8YnI+DQomZ3Q7Jmd0O211bHRpcGxlIGRldmljZXMgYW5zd2VyIHRvIHRoZSBzZXNzaW9u LiBIZXJlLCB1c2VyIG1heSBtb3ZlIGZyb20gb25lPGJyPg0KJmd0OyZndDtkZXZpY2U8YnI+DQom Z3Q7Jmd0Oyhtb2JpbGUpIHRvIGFub3RoZXIgZGV2aWNlIChkZXNrdG9wKSB3aXRoaW4gdGhlIHNl c3Npb24gYW5kIHdpc2hlcyB0bzxicj4NCiZndDsmZ3Q7Y29udGludWUgdGhlIHNlc3Npb24gd2l0 aCB0aGUgbGFzdCBhbnN3ZXIuIFBsZWFzZSBub3RlIHRoYXQgd2Vic2l0ZSBpczxicj4NCiZndDsm Z3Q7ZmxleGlibGUgdG8gcHJvdmlkZSB0aGlzIHNlcnZpY2UuPGJyPg0KJmd0OyZndDsmZ3Q7IDIp ICZuYnNwOyAmbmJzcDsgJm5ic3A7UkZDIDMyNjEgU0lQIFVBIG9mZmVyL2Fuc3dlciBoYW5kbGlu ZyB3LnIudCBJTlZJVEUgd2l0aCBTRFA8YnI+DQomZ3Q7dG88YnI+DQomZ3Q7Jmd0O211bHRpcGxl IDJ4eCB3aXRoIFNEUCBoYW5kbGluZyBzY2VuYXJpbyB1c2luZyBKU0VQPGJyPg0KJmd0OyZndDsm Z3Q7IDMpICZuYnNwOyAmbmJzcDsgJm5ic3A7QW5vdGhlciBTSVAgdXNlY2FzZSBjb3VsZCBiZSBt dWx0aXBsZSAxOHggcmVzcG9uc2VzIHdpdGggU0RQPGJyPg0KJmd0OyZndDtmb3IgSU5WSVRFIHdp dGggU0RQIGFuZCBtdWx0aXBsZSAyeHggcmVzcG9uc2VzIHdpdGhvdXQgU0RQIGJ1dCBvcmRlcjxi cj4NCiZndDsmZ3Q7d2l0aGluIDE4eCBhbmQgMjAwIGFyZSBub3Qgc2FtZS4gU2F5IDJ4eCBvZiB0 aGUgc2Vjb25kIDE4eCBpcyByZWNlaXZlZDxicj4NCiZndDsmZ3Q7YXMgdGhlIGZpcnN0IDJ4eC4g SGVyZSwgd2UgbmVlZCB0byBrbm93IGhvdyBzZWNvbmQgMTh4IGlzIGhhbmRsZWQgYW5kPGJyPg0K Jmd0OyZndDthbHNvLCB0aGUgc3Vic2VxdWVudCAyeHggaXMgaGFuZGxlZC48YnI+DQomZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgT2YgY291cnNlLCBpdCBpcyBwb3NzaWJsZSB0byBidWls ZCBtb3JlIHVzZWNhc2VzIGFyb3VuZCB0aGlzIGFyZWEuIEFzPGJyPg0KJmd0OyZndDt3ZSBtYWRl IHNpZ25hbGluZyBvdXRzaWRlIHRoZSBzY29wZSBvZiBXZWJSVEMsIGl0IGlzIHVwdG8gSlM8YnI+ DQomZ3Q7Jmd0O2FwcGxpY2F0aW9uIHRvIGRlY2lkZSB0aGUgb3JkZXIgaW4gd2hpY2ggb2ZmZXIv YW5zd2VyIGhhcHBlbnMuIEknbSBub3Q8YnI+DQomZ3Q7Jmd0O3JlbGF0aW5nIG9mZmVyL2Fuc3dl ciBGU00gd2l0aCBzZXNzaW9uIGVzdGFibGlzaG1lbnQgc3RhdGUgbGlrZSAxOHgsPGJyPg0KJmd0 OyZndDsyeHggYnV0IEknbSBpbnRlcmVzdGVkIGluIGtub3dpbmcgYnJvd3NlciBtZWRpYSBwbGFu ZSBiZWhhdmlvciBpbjxicj4NCiZndDsmZ3Q7ZGlmZmVyZW50IHN0YXRlIG9mIG9mZmVyL2Fuc3dl ciBoYW5kbGluZyBieSB3aGljaCBKUyBhcHBsaWNhdGlvbjxicj4NCiZndDsmZ3Q7YmVoYXZlcyBj b25zaXN0ZW50bHkgaW4gYWxsIGJyb3dzZXJzLjxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7Jmd0OyBUaGFua3M8YnI+DQomZ3Q7Jmd0OyZndDsgUGFydGhhPGJyPg0KJmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IEZyb206IEp1c3RpbiBVYmVydGkg W21haWx0bzo8YSBocmVmPSJtYWlsdG86anViZXJ0aUBnb29nbGUuY29tIj5qdWJlcnRpQGdvb2ds ZS5jb208L2E+XTxicj4NCiZndDsmZ3Q7Jmd0OyBTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAxNCwg MjAxMiAxMTozNiBQTTxicj4NCiZndDsmZ3Q7Jmd0OyBUbzogUmF2aW5kcmFuLCBQYXJ0aGFzYXJh dGhpPGJyPg0KJmd0OyZndDsmZ3Q7IENjOiA8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3Jn Ij5ydGN3ZWJAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86cHVibGljLXdlYnJ0Y0B3My5v cmciPg0KcHVibGljLXdlYnJ0Y0B3My5vcmc8L2E+PGJyPg0KJmd0OyZndDsmZ3Q7IFN1YmplY3Q6 IFJlOiBTaW5nbGUgb2ZmZXIgd2l0aCBtdWx0aXBsZSBhbnN3ZXIgaGFuZGxpbmcgaW4gSlNFUCBb d2FzPGJyPg0KJmd0OyZndDtSRTogW3J0Y3dlYl0gTmV3IEpTRVAgZHJhZnQgcG9zdGVkXTxicj4N CiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBQYXJ0aGEsPGJyPg0KJmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsmZ3Q7IEkgbmVlZCBtb3JlIGluZm9ybWF0aW9uIGFib3V0IHRoZSB1c2Ug Y2FzZSB0byBwcm92aWRlIGFuIGFjY3VyYXRlPGJyPg0KJmd0OyZndDtyZXNwb25zZS4gQXMgbWVu dGlvbmVkIGluIG15IGVhcmxpZXIgbWFpbCwgYXJlIGJvdGggYW5zd2VycyAyeHg8YnI+DQomZ3Q7 Jmd0O3Jlc3BvbnNlcz88YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgT24gVHVl LCBGZWIgMTQsIDIwMTIgYXQgMTI6MTcgUE0sIFJhdmluZHJhbiwgUGFydGhhc2FyYXRoaTxicj4N CiZndDsmZ3Q7Jmx0OzxhIGhyZWY9Im1haWx0bzpwcmF2aW5kcmFuQHNvbnVzbmV0LmNvbSI+cHJh dmluZHJhbkBzb251c25ldC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyZndDsgSGkg SnVzdGluLDxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBJbiB0aGlzIG1haWwg dGhyZWFkLCBMZXQgdXMgZGVmaW5lIHRoZSBiZWhhdmlvciBvZiBtdWx0aXBsZSAoYXRsZWFzdDxi cj4NCiZndDsmZ3Q7dHdvKSBhbnN3ZXJzIGZvciB0aGUgc2luZ2xlIG9mZmVyIGluIFdlYlJUQyBi cm93c2VyLiAmbmJzcDtOb3csIFBsZWFzZSBsZXQ8YnI+DQomZ3Q7Jmd0O21lIGtub3cgeW91ciBv cGluaW9uIGZvciBteSBiZWxvdyBtYWlsLjxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 Jmd0OyBUaGFua3M8YnI+DQomZ3Q7Jmd0OyZndDsgUGFydGhhPGJyPg0KJmd0OyZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsmZ3Q7IEZyb206IEp1c3RpbiBVYmVydGkgW21haWx0bzo8YSBocmVmPSJtYWls dG86anViZXJ0aUBnb29nbGUuY29tIj5qdWJlcnRpQGdvb2dsZS5jb208L2E+XTxicj4NCiZndDsm Z3Q7Jmd0OyBTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAxNCwgMjAxMiA5OjQ3IFBNPGJyPg0KJmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IFRvOiBSYXZpbmRyYW4sIFBhcnRoYXNhcmF0aGk8 YnI+DQomZ3Q7Jmd0OyZndDsgQ2M6IDxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciPnJ0 Y3dlYkBpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpwdWJsaWMtd2VicnRjQHczLm9yZyI+ DQpwdWJsaWMtd2VicnRjQHczLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyZndDsgU3ViamVjdDogUmU6 IFNpbmdsZSBvZmZlciB3aXRoIG11bHRpcGxlIGFuc3dlciBoYW5kbGluZyBpbiBKU0VQIFt3YXM8 YnI+DQomZ3Q7Jmd0O1JFOiBbcnRjd2ViXSBOZXcgSlNFUCBkcmFmdCBwb3N0ZWRdPGJyPg0KJmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsmZ3Q7IE9uIFR1ZSwgRmViIDE0LCAyMDEyIGF0IDY6MzkgQU0sIFJhdmluZHJhbiwgUGFydGhh c2FyYXRoaTxicj4NCiZndDsmZ3Q7Jmx0OzxhIGhyZWY9Im1haWx0bzpwcmF2aW5kcmFuQHNvbnVz bmV0LmNvbSI+cHJhdmluZHJhbkBzb251c25ldC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7 Jmd0OyZndDsgSGkgSnVzdGluLDxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBJ dCB3aWxsIGJlIGdvb2QgdG8gbWVudGlvbiBpbiB0aGUgSlNFUCBkcmFmdCAmbmJzcDt0aGF0IG11 bHRpcGxlIGFuc3dlcnM8YnI+DQomZ3Q7Jmd0O2ZvciBzaW5nbGUgb2ZmZXIgd2lsbCBub3QgbGVh ZCB0byBSVFAgTWl4aW5nIGFuZCBXZWJSVEMgY2xpZW50IGFjdHMgYXM8YnI+DQomZ3Q7Jmd0O1JU UCBFbmRwb2ludC48YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgRmFpbGluZyB0 aGUgc2Vjb25kIEFuc3dlciB3aWxsIGJlIGxpbWl0aW5nIHRoZSBwcm92aXNpb24gaW4gUkZDIDMy NjQ8YnI+DQomZ3Q7Jmd0O29mZmVyL2Fuc3dlciBpdHNlbGYgYXMgUkZDIDMyNjQgc3VwcG9ydHMg c2luZ2xlIG9mZmVyIHdpdGggbXVsdGlwbGU8YnI+DQomZ3Q7Jmd0O2Fuc3dlci4gQWxzbywgaXQg aXMgYmV0dGVyIHRvIGRlZmluZSB0aGUgYmVoYXZpb3IgaW4gQVBJIHJhdGhlciB0aGFuPGJyPg0K Jmd0OyZndDtwdXR0aW5nIHRoaXMgc2NlbmFyaW8gaW4gdGhlIGJyb3dzZXIgaW1wbGVtZW50YXRp b24gc3BlY2lmaWMuIEluIHNpbXBsZTxicj4NCiZndDsmZ3Q7c2NlbmFyaW9zIChsaWtlIGFsZXJ0 aW5nIHdpdGggb25lIGFuc3dlciwgY29ubmVjdCB3aXRoIHNlY29uZCBhbnN3ZXIpLDxicj4NCiZn dDsmZ3Q7cmVwbGFjaW5nIHRoZSBwcmV2aW91cyBBTlNXRVIgd2lsbCBiZSBleHBlY3RlZCBiZWhh dmlvci4gVGhpcyBtYXkgbm90PGJyPg0KJmd0OyZndDtiZSBkZXNpcmVkIGJlaGF2aW9yIGluIGNh c2UgdHdvIGNvbm5lY3QgcmVzcG9uc2VzIGZyb20gZGlmZmVyZW50IFdlYlJUQzxicj4NCiZndDsm Z3Q7Y2xpZW50cyByZWNlaXZlZCB3aXRoIGRpZmZlcmVudCBhbnN3ZXJzICZuYnNwO2J1dCB0aGVy ZSBpcyBubyBvdGhlcjxicj4NCiZndDsmZ3Q7YWx0ZXJuYXRpdmUgc29sdXRpb24gcG9zc2libGUg d2l0aG91dCBtaXhpbmcuPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IERvIHlv dSBuZWVkIHRvIHN1cHBvcnQgMiBmaW5hbCBhbnN3ZXJzLCBvciB3b3VsZCB0aGUgcHJvdmlzaW9u YWw8YnI+DQomZ3Q7Jmd0O2Fuc3dlciBzdXBwb3J0IHByb3ZpZGVkIHZpYSBTRFBfUFJBTlNXRVIg d29yayBmb3IgeW91Pzxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBJTU8sIGl0 IGlzIGJldHRlciB0byBkZWZpbmUgaXQgZXhwbGljaXRseSBpbiBKU0VQIHRoYXQgJnF1b3Q7bGF0 ZXN0IEFOU1dFUjxicj4NCiZndDsmZ3Q7dG8gdGhlIG9mZmVyIHdpbGwgcmVwbGFjZSB0aGUgZXhp c3RpbmcgYW5zd2VyIGlzIHRoZSBleHBlY3RlZCBiZWhhdmlvcjxicj4NCiZndDsmZ3Q7JnF1b3Q7 LiBBbHNvLCBQbGVhc2UgbWVudGlvbmVkIHRoYXQgSlMgYXBwbGljYXRpb24gaXMgcmVzcG9uc2li bGUgZm9yPGJyPg0KJmd0OyZndDtkaXNjYXJkaW5nICh0ZXJtaW5hdGluZykgcHJldmlvdXMgQU5T V0VSIG5vdGlmaWNhdGlvbi4gJm5ic3A7IFBsZWFzZSBsZXQgbWU8YnI+DQomZ3Q7Jmd0O3lvdXIg b3BpbmlvbiBvbiB0aGlzIGNsb3N1cmUuPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsm Z3Q7IFRoYW5rczxicj4NCiZndDsmZ3Q7Jmd0OyBQYXJ0aGE8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyZndDsgRnJvbTogSnVzdGluIFViZXJ0aSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0 bzpqdWJlcnRpQGdvb2dsZS5jb20iPmp1YmVydGlAZ29vZ2xlLmNvbTwvYT5dPGJyPg0KJmd0OyZn dDsmZ3Q7IFNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDE0LCAyMDEyIDc6MjkgUE08YnI+DQomZ3Q7 Jmd0OyZndDsgVG86IFJhdmluZHJhbiwgUGFydGhhc2FyYXRoaTxicj4NCiZndDsmZ3Q7Jmd0OyBD YzogPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+cnRjd2ViQGlldGYub3JnPC9hPjsg PGEgaHJlZj0ibWFpbHRvOnB1YmxpYy13ZWJydGNAdzMub3JnIj4NCnB1YmxpYy13ZWJydGNAdzMu b3JnPC9hPjxicj4NCiZndDsmZ3Q7Jmd0OyBTdWJqZWN0OiBSZTogU2luZ2xlIG9mZmVyIHdpdGgg bXVsdGlwbGUgYW5zd2VyIGhhbmRsaW5nIGluIEpTRVAgW3dhczxicj4NCiZndDsmZ3Q7UkU6IFty dGN3ZWJdIE5ldyBKU0VQIGRyYWZ0IHBvc3RlZF08YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyZndDsgUmVnYXJkaW5nIHlvdXIgcHJldmlvdXMgbWFpbCwgYW4gQU5TV0VSIGFmdGVyIGFu IEFOU1dFUiB3b3VsZCBlaXRoZXI8YnI+DQomZ3Q7Jmd0O2ZhaWwgKGlmIHdlIHdhbnRlZCB0byBz aW1wbGlmeSksIG9yIHJlcGxhY2UgdGhlIHByZXZpb3VzIEFOU1dFUjxicj4NCiZndDsmZ3Q7KGVz c2VudGlhbGx5IHRoZSBzYW1lIGFzIGlmIHlvdSBoYWQgZG9uZSBzZXRMb2NhbERlc2NyaXB0aW9u KE9GRkVSLDxicj4NCiZndDsmZ3Q7bG9jYWxEZXNjcmlwdGlvbikgZm9sbG93ZWQgYnkgc2V0UmVt b3RlRGVzY3JpcHRpb24oQU5TV0VSLCBhbnN3ZXIyKS48YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyZndDsgSW4gbm8gY2FzZSB3b3VsZCBpdCBtaXggdGhlIGRlc2NyaXB0aW9ucy9tZWRp YSBmcm9tIGJvdGggYW5zd2Vycy48YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsg T3RoZXIgY29tbWVudHMgaW5saW5lIGJlbG93Ljxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7Jmd0OyBPbiBUdWUsIEZlYiAxNCwgMjAxMiBhdCAxOjI0IEFNLCBSYXZpbmRyYW4sIFBhcnRo YXNhcmF0aGk8YnI+DQomZ3Q7Jmd0OyZsdDs8YSBocmVmPSJtYWlsdG86cHJhdmluZHJhbkBzb251 c25ldC5jb20iPnByYXZpbmRyYW5Ac29udXNuZXQuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0 OyZndDsmZ3Q7IEhpIEp1c3Rpbiw8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsg QWRkaW5nIHRvIG15IGVhcmxpZXIgbWFpbCwgSW4gY2FzZSBhbnN3ZXIyIFNEUCBpcyB1cGRhdGVk IGluIG9mZmVyZXIxPGJyPg0KJmd0OyZndDticm93c2VyIHdpdGhvdXQgbm90aWZ5aW5nIGFuc3dl cmVyMSwgdGhlbiBhbnN3ZXIxIHdpbGwgY29udGludWUgdG88YnI+DQomZ3Q7Jmd0O3RyYW5zbWl0 IFJUUCB3aGljaCBtYXkgbm90IGJlIGRlc2lyZWQgYmVoYXZpb3IuIElNTywgd2UgbmVlZCB0byBk ZWZpbmU8YnI+DQomZ3Q7Jmd0O3RoaXMgYmVoYXZpb3IgY2xlYXJseSBpbiBvZmZlcmVyIHNpZGUu IFNvbWUgb2YgdGhlIHBvc3NpYmxlIHNvbHV0aW9uczxicj4NCiZndDsmZ3Q7YXJlPGJyPg0KJmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IDEpICZuYnNwOyAmbmJzcDsgJm5ic3A7b2ZmZXJl cjEgaGFzIHRvIHNlbmQgYXRsZWFzdCBSVENQIEJZRSBwYWNrZXRzIHRvd2FyZHM8YnI+DQomZ3Q7 Jmd0O2Fuc3dlcmVyMSB3aGlsZSBhY2NlcHRpbmcgdGhlIGFuc3dlcmVyMiBTRFAuPGJyPg0KJmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IDIpICZuYnNwOyAmbmJzcDsgJm5ic3A7VGhyb3cg Y2FsbGJhY2sgdG8gY2xlYXIgYW5zd2VyMSBTRFAgdG93YXJkcyBvZmZlcmVySlMuPGJyPg0KJmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IFRoZSBhcHBsaWNh dGlvbiB3aGljaCBjYWxsZWQgc2V0UmVtb3RlRGVzY3JpcHRpb24gdHdpY2Ugc2hvdWxkIGhhdmU8 YnI+DQomZ3Q7Jmd0O3RoZSBiZXN0IGlkZWEgYWJvdXQgd2hhdCBpcyBnb2luZyBvbiwgYW5kIHRo ZXJlZm9yZSBpcyByZXNwb25zaWJsZSBmb3I8YnI+DQomZ3Q7Jmd0O25vdGlmeWluZyBhbnN3ZXJl cjEgdGhhdCBpdHMgYW5zd2VyIGhhcyBiZWVuIGRpc2NhcmRlZCwgaWYgaXQgbWFrZXM8YnI+DQom Z3Q7Jmd0O3NlbnNlIHRvIGRvIHNvLiBObyBjYWxsYmFjayBzaG91bGQgYmUgbmVlZGVkIGhlcmUu PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IFBs ZWFzZSBsZXQgbWUga25vdyB5b3VyIG9waW5pb24gaGVyZS48YnI+DQomZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyZndDsgVGhhbmtzPGJyPg0KJmd0OyZndDsmZ3Q7IFBhcnRoYTxicj4NCiZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBGcm9tOiBSYXZpbmRyYW4sIFBhcnRoYXNhcmF0aGk8 YnI+DQomZ3Q7Jmd0OyZndDsgU2VudDogVHVlc2RheSwgRmVicnVhcnkgMTQsIDIwMTIgMTI6MDcg QU08YnI+DQomZ3Q7Jmd0OyZndDsgVG86ICdKdXN0aW4gVWJlcnRpJzsgPGEgaHJlZj0ibWFpbHRv OnJ0Y3dlYkBpZXRmLm9yZyI+cnRjd2ViQGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOnB1 YmxpYy13ZWJydGNAdzMub3JnIj4NCnB1YmxpYy13ZWJydGNAdzMub3JnPC9hPjxicj4NCiZndDsm Z3Q7Jmd0OyBTdWJqZWN0OiBTaW5nbGUgb2ZmZXIgd2l0aCBtdWx0aXBsZSBhbnN3ZXIgaGFuZGxp bmcgaW4gSlNFUCBbd2FzIFJFOjxicj4NCiZndDsmZ3Q7W3J0Y3dlYl0gTmV3IEpTRVAgZHJhZnQg cG9zdGVkXTxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBIaSBKdXN0aW4sPGJy Pg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IEluIHRoZSBkcmFmdCwgaXQgaXMgbm90 IHNwZWxsZWQgb3V0IGV4cGxpY2l0bHkgd2hhdCBpcyB0aGUgZXhwZWN0ZWQ8YnI+DQomZ3Q7Jmd0 O2JlaGF2aW9yIGluIG9mZmVyZXIgYnJvd3NlciBpbiBjYXNlIG11bHRpcGxlIGFuc3dlciBpcyBy ZWNlaXZlZCBmb3I8YnI+DQomZ3Q7Jmd0O3NpbmdsZSBvZmZlci4gT2ZmZXIvYW5zd2VyIGV4Y2hh bmdlIGluIG9mZmVyZXIgaXMgYXMgZm9sbG93czo8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyZndDsgT2ZmZXJlckpTLSZndDtPZmZlcmVyVUE6IHZhciBvZmZlciA9IHBjLmNyZWF0ZU9m ZmVyKG51bGwpOzxicj4NCiZndDsmZ3Q7Jmd0OyBPZmZlcmVySlMtJmd0O09mZmVyZXJVQTogcGMu c2V0TG9jYWxEZXNjcmlwdGlvbihTRFBfT0ZGRVIsIG9mZmVyKTs8YnI+DQomZ3Q7Jmd0OyZndDsg T2ZmZXJlckpTLSZndDtPZmZlcmVyVUE6ICZuYnNwO3BjLnNldFJlbW90ZURlc2NyaXB0aW9uKFNE UF9BTlNXRVIsIGFuc3dlcjEpOzxicj4NCiZndDsmZ3Q7Jmd0OyBPZmZlcmVyVUEtJmd0O0Fuc3dl cmVyMVVBOiAmbHQ7bWVkaWEmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IE9mZmVyZXJKUy0mZ3Q7T2Zm ZXJlclVBOiAmbmJzcDtwYy5zZXRSZW1vdGVEZXNjcmlwdGlvbihTRFBfQU5TV0VSLCBhbnN3ZXIy KTs8YnI+DQomZ3Q7Jmd0OyZndDsgT2ZmZXJlclVBLSZndDtBbnN3ZXJlcj9VQTogJmx0O21lZGlh Jmd0Oz88YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgTXkgdW5kZXJzdGFuZGlu ZyBpcyB0aGF0ICZxdW90O2Fuc3dlcjImcXVvdDsgd2lsbCB1cGRhdGUgJnF1b3Q7YW5zd2VyMSZx dW90OyBpbiBicm93c2VyPGJyPg0KJmd0OyZndDthbmQgc3RhcnRpbmcgc2VuZGluZy9yZWNlaXZp bmcgbWVkaWEgdG93YXJkcyBhbnN3ZXIyIG1lZGlhIElQIGFuZCBwb3J0Ljxicj4NCiZndDsmZ3Q7 Q291bGQgeW91IHBsZWFzZSBleHBsYWluIHRoZSBleHBlY3RlZCBiZWhhdmlvciBpbiBvZmZlcmVy IGJyb3dzZXI8YnI+DQomZ3Q7Jmd0O3doZXRoZXIgaXQgdXBkYXRlcyB0aGUgbWVkaWEgc3RyZWFt IGJhc2VkIG9uIHRoZSBsYXN0IGFuc3dlciBvciBtaXhlczxicj4NCiZndDsmZ3Q7Ym90aCBhbnN3 ZXJlci48YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgVGhhbmtzPGJyPg0KJmd0 OyZndDsmZ3Q7IFBhcnRoYTxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBGcm9t OiA8YSBocmVmPSJtYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmciPnJ0Y3dlYi1ib3VuY2Vz QGlldGYub3JnPC9hPiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpydGN3ZWItYm91bmNlc0BpZXRm Lm9yZyI+cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbjxicj4NCiZndDsmZ3Q7QmVoYWxm IE9mIEp1c3RpbiBVYmVydGk8YnI+DQomZ3Q7Jmd0OyZndDsgU2VudDogVGh1cnNkYXksIEZlYnJ1 YXJ5IDA5LCAyMDEyIDI6MjcgQU08YnI+DQomZ3Q7Jmd0OyZndDsgVG86IDxhIGhyZWY9Im1haWx0 bzpydGN3ZWJAaWV0Zi5vcmciPnJ0Y3dlYkBpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpw dWJsaWMtd2VicnRjQHczLm9yZyI+DQpwdWJsaWMtd2VicnRjQHczLm9yZzwvYT48YnI+DQomZ3Q7 Jmd0OyZndDsgU3ViamVjdDogW3J0Y3dlYl0gTmV3IEpTRVAgZHJhZnQgcG9zdGVkPGJyPg0KJmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IE5vdyBhdmFpbGFibGUgYXQgPGEgaHJlZj0iaHR0 cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC11YmVydGktcnRjd2ViLWpzZXAtIiB0YXJnZXQ9Il9i bGFuayI+DQpodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LXViZXJ0aS1ydGN3ZWItanNlcC08 L2E+PGJyPg0KJmd0OyZndDswMS50eHQ8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZn dDsgSW5jbHVkZXMgY2hhbmdlcyBiYXNlZCBvbiBpbXBsZW1lbnRhdGlvbiBmZWVkYmFjaywgYW5k IEkgYmVsaWV2ZSBpdDxicj4NCiZndDsmZ3Q7YWRkcmVzc2VzIG1vc3Qgb2YgdGhlIGNvbmNlcm5z IHJhaXNlZCBpbiBsYXN0IHdlZWsncyBpbnRlcmltIG1lZXRpbmdzOjxicj4NCiZndDsmZ3Q7Jmd0 OyAtIEluaXRpYWwgZG9jdW1lbnRhdGlvbiBwcm92aWRlZCBmb3IgZWFjaCBBUEkgY2FsbCwgYW5k IHdoYXQgc3RhdGU8YnI+DQomZ3Q7Jmd0O2NoYW5nZXMgaXQgY2F1c2VzPGJyPg0KJmd0OyZndDsm Z3Q7IC0gTW9yZSBleGFtcGxlcywgaW5jbHVkaW5nIGEgY29tcGxldGUgYmFzaWMgc2FtcGxlIGFw cGxpY2F0aW9uPGJyPg0KJmd0OyZndDsmZ3Q7IC0gU2ltcGxpZmllZCBhcHByb2FjaCB0byB0cmlj a2xlIGNhbmRpZGF0ZSBoYW5kbGluZzxicj4NCiZndDsmZ3Q7Jmd0OyAtIFJlc29sdmVkIGNvbmNl cm5zIGFib3V0IGhvdyB0byBzZXBhcmF0ZSBTRFAgYXR0cmlidXRlcyBpbnRvIG1lZGlhIC88YnI+ DQomZ3Q7Jmd0O3RyYW5zcG9ydDxicj4NCiZndDsmZ3Q7Jmd0OyAtIFByb3ZpZGVkIGVuY2Fwc3Vs YXRpb24gZm9yIFNEUCBibG9icyBhbmQgSUNFIGNhbmRpZGF0ZSBsaW5lcywgaW48YnI+DQomZ3Q7 Jmd0OyZndDsgdGhlPGJyPg0KJmd0OyZndDtldmVudCB3ZSB3YW50IHRvIGNoYW5nZSBlbmNvZGlu Z3Mgb3IgcHJvdmlkZSBoZWxwZXIgZnVuY3Rpb25zIGZvciBKUzxicj4NCiZndDsmZ3Q7Jmd0OyAt IFByb3ZpZGVkIG1lY2hhbmlzbSBmb3IgbGltaXRpbmcgY2FuZGlkYXRlcyB0byBUVVJOLW9ubHk8 YnI+DQomZ3Q7Jmd0OyZndDsgLSBSZXNvbHZlZCBzZXZlcmFsIGltcGxlbWVudGF0aW9uIGlzc3Vl czxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBJIGhhdmUgbm90IHlldCBhZGRy ZXNzZWQgdGhlIG5vbi1vdmVybGFwcGluZyBjb2RlYyBjb25jZXJuIG1lbnRpb25lZDxicj4NCiZn dDsmZ3Q7aW4gdGhlIGludGVyaW0gbWVldGluZy4gSSB0aGluayB0aGVyZSBhcmUgd2F5cyBvZiBo YW5kbGluZyB0aGlzIGVpdGhlcjxicj4NCiZndDsmZ3Q7aW4gdGhlIGFwcGxpY2F0aW9uIG9yIHRo ZSBpbXBsZW1lbnRhdGlvbiwgYnV0IEkgd2FudGVkIHRvIGdldCB0aGlzIC0wMTxicj4NCiZndDsm Z3Q7b3V0IGZpcnN0IGZvciBmZWVkYmFjay48YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyZndDsgcnRjd2Vi IG1haWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86cnRjd2ViQGll dGYub3JnIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWI8L2E+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_387F9047F55E8C42850AD6B3A7A03C6C0E0406FAinbamail01sonus_-- From juberti@google.com Fri Feb 17 06:49: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 3166921F8749 for ; Fri, 17 Feb 2012 06:49:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.461 X-Spam-Level: X-Spam-Status: No, score=-102.461 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hlr+pyIPc4mn for ; Fri, 17 Feb 2012 06:49:55 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 347E221F8741 for ; Fri, 17 Feb 2012 06:49:55 -0800 (PST) Received: by qafi29 with SMTP id i29so878816qaf.10 for ; Fri, 17 Feb 2012 06:49:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=uQJV4vvJNCGa4Rcx0Y1AOBEzloauu0DmBoqit3ZLLrw=; b=d1CiUgyDvyMXAGdCZp4jv84XLJgJf1nhlCMyRE0/TadAPQ3C2Lk4EwHk+CCr6JJLQ3 GXoqGMKHbiBFQOb53Iw8umeBPwcYVQ+r2CWH4vqzZXS/v8Yr6YmmcHSiAcSNNRPWbAer EojYGFxHrtmXEJ1XZRFnX5HhhxdUQw3zRK7Og= Received: by 10.229.78.89 with SMTP id j25mr5155004qck.46.1329490194457; Fri, 17 Feb 2012 06:49:54 -0800 (PST) Received: by 10.229.78.89 with SMTP id j25mr5154994qck.46.1329490194298; Fri, 17 Feb 2012 06:49:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.29.195 with HTTP; Fri, 17 Feb 2012 06:49:34 -0800 (PST) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3D8C5AD8@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C3D87E060@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C3D8C5AD8@ESESSCMS0356.eemea.ericsson.se> From: Justin Uberti Date: Fri, 17 Feb 2012 09:49:34 -0500 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=00235429d374c376c004b92a0eca X-System-Of-Record: true X-Gm-Message-State: ALoCoQnwufBiJmTwiljrM5Okj+xlZNTqHn382VJueoh7yXl65OT6wvO1apM9R2a5gJTIQUNoZrMdFNMOyUkP7pKAcLU0P8sY2KZBt6KfeS+4rHGLyAgmsl3lcRX5Tmow5bCKcXKoSx7OcVHBTdNXvFjg9SXdOHoKow== Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] JSEP-01: SDP_PRANSWER and FEDEX use-case 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, 17 Feb 2012 14:49:56 -0000 --00235429d374c376c004b92a0eca Content-Type: text/plain; charset=UTF-8 On Fri, Feb 17, 2012 at 3:33 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > > Hi, > > >> Section 6.1.4 of jsep-01 says: > >> > >> "SDP_PRANSWER indicates that a description should be > parsed as an > >> answer, but not a final answer, and so should not result > in the > >> starting of media transmission. A description used as a > SDP_PRANSWER > >> may be applied as a response to a SDP_OFFER, or an update > to a > >> previously sent SDP_PRANSWER." > >> > >> > >> Section 7.6 shows a SIP early media (FEDEX) use-case, where an SDP > answer received in a SIP 18x response is provided to the browser as a > SDP_PRANSWER. > >> > >> > >> Q1: Since SDP_PRANSWER is not supposed to start media > transmission, how will the use-case work? As far as I know, media > transmission is needed for the FEDEX use-case. > > > > > > I think this is just me being unclear. When I say "start media > transmission", I mean that when the browser gets a SDP_PRANSWER > > in response to an offer, the browser will not start transmitting media. > However, it will play out any media that is received > > after the offer is installed, and the gateway can start sending media at > any time after it gets the offer. > > Again, you could achieve that using SDP_ANSWER and a direction attribute > (a=recvonly). I don't think we need SDP_PRANSWER for unidirectional media > purpose. > > (And, as was mentioned, there may actually be a need to also transmit > media for the FEDEX case) > > > >> Q2: The draft doesn't really specify what SDP_PRANSWER is used for. I > understand that it means that a "final" answer > >> may be provided later, but it doesn't really say what the a browser > would do with an SDP_PRANSWER - especially since > >> it doesn't seem to enable media. > > > > > > SDP_PRANSWER allows, among other things, the callee's ICE and SRTP info > to be provided so that early media can > > be received by the caller. I think it should make more sense given my > answer to #1. > > As I replied to #1, I don't think we need SDP_PRANSWER to establish > unidirectional media, so I would like to know what those "other things" are > :) > > > >> Q3: Assuming we would allow multiple SDP_ANSWER (see separate thread), > is there a need for SDP_PRANSWER? > > > > > > SDP_PRANSWER has slightly different semantics in that it is not intended > to indicate consent by the callee, whereas SDP_ANSWER does. > > What does the browser do with that information? > > My understanding was that the browser is going to use media plane > mechanisms (e.g. ICE) for callee consent. > When I say "consent" here, I mean the user has given permission to start transmitting their media (i.e., "answered the call"). This is distinct from the ICE-level "sending media to the right place" mechanisms. Anyway, I went and looked at sendonly/recvonly/inactive handling and I think I understand what you are suggesting. Let me see if I can distill this into some rules: - createOffer/Answer generates a=sendrecv offers/answers by default. - Installing an a=sendonly/sendrecv description as an answer (via setLocalDescription or setRemoteDescription) causes the browser to start sending media from attached streams. - Installing an a=recvonly/sendrecv description as an answer (via setLocalDescription or setRemoteDescription) causes the browser to start playing out received media. - Multiple answers can be received; the most recent answer is the one that is used. Which allow for these scenarios: - If an application wants to send an early response, but not start sending/receving media (i.e. it is simply for faster call setup), it can create, apply, and send an a=inactive answer. - When that application sends its final response, indicating it wants to send/receive media, it can apply/send an a=sendrecv answer. - In the 1-800-FEDEX case, the answer received from 1-800-FEDEX may be a "early response", but from the perspective of JSEP, it is a typical answer with a=sendrecv. Does this sound right to you? If so, I agree we can probably do away with PRANSWER, unless others see something that we're overlooking. --00235429d374c376c004b92a0eca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Feb 17, 2012 at 3:33 AM, Christe= r Holmberg <christer.holmberg@ericsson.com> wrote:

Hi,

>> =C2=A0 =C2=A0 =C2=A0Section 6.1.4 of jsep-01 says:
>>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"SDP_PRANSWER= indicates that a description should be parsed as an
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 answer, but not a= final answer, and so should not result in the
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 starting of media= transmission. A description used as a SDP_PRANSWER
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 may be applied as= a response to a SDP_OFFER, or an update to a
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 previously sent S= DP_PRANSWER."
>>
>>
>> =C2=A0 =C2=A0 =C2=A0Section 7.6 shows a SIP early media (FEDEX) us= e-case, where an SDP answer received in a SIP 18x response is provided to t= he browser as a SDP_PRANSWER.
>>
>>
>> =C2=A0 =C2=A0 =C2=A0Q1: Since SDP_PRANSWER is not supposed to star= t media transmission, how will the use-case work? As far as I know, media t= ransmission is needed for the FEDEX use-case.
>
>
> I think this is just me being unclear. When I say "start media tr= ansmission", I mean that when the browser gets a SDP_PRANSWER
> in response to an offer, the browser will not start transmitting media= . However, it will play out any media that is received
> after the offer is installed, and the gateway can start sending media = at any time after it gets the offer.

Again, you could achieve that using SDP_ANSWER and a direction attrib= ute (a=3Drecvonly). I don't think we need SDP_PRANSWER for unidirection= al media purpose.

(And, as was mentioned, there may actually be a need to also transmit media= for the FEDEX case)


>> Q2: The draft doesn't really specify what SDP_PRANSWER is used= for. I understand that it means that a "final" answer
>> may be provided later, but it doesn't really say what the a br= owser would do with an SDP_PRANSWER - especially since
>> it doesn't seem to enable media.
>
>
> SDP_PRANSWER allows, among other things, the callee's ICE and SRTP= info to be provided so that early media can
> be received by the caller. I think it should make more sense given my = answer to #1.

As I replied to #1, I don't think we need SDP_PRANSWER to establi= sh unidirectional media, so I would like to know what those "other thi= ngs" are :)


>> Q3: Assuming we would allow multiple SDP_ANSWER (see separate thre= ad), is there a need for SDP_PRANSWER?
>
>
> SDP_PRANSWER has slightly different semantics in that it is not intend= ed to indicate consent by the callee, whereas SDP_ANSWER does.

What does the browser do with that information?

My understanding was that the browser is going to use media plane mechanism= s (e.g. ICE) for callee consent.

When I= say "consent" here, I mean the user has given permission to star= t transmitting their media (i.e., "answered the call"). This is d= istinct from the ICE-level "sending media to the right place" mec= hanisms.=C2=A0

Anyway, I went and looked at sendonly/recvonly/inactive= handling and I think I understand what you are suggesting. Let me see if I= can distill this into some rules:
- createOffer/Answer generates= a=3Dsendrecv offers/answers by default.
- Installing an a=3Dsendonly/sendrecv description as an answer (via se= tLocalDescription or setRemoteDescription) causes the browser to start send= ing media from attached streams.
- Installing an a=3Drecvonly/sen= drecv description as an answer (via setLocalDescription or setRemoteDescrip= tion) causes the browser to start playing out received media.
- Multiple answers can be received; the most recent answer is the one = that is used.

Which allow for these scenarios:
- If an application wants to send an early response, but not start s= ending/receving media (i.e. it is simply for faster call setup), it can cre= ate, apply, and send an a=3Dinactive answer.
- When that application sends its final response, indicating it wants = to send/receive media, it can apply/send an a=3Dsendrecv answer.
= - In the 1-800-FEDEX case, the answer received from 1-800-FEDEX may be a &q= uot;early response", but from the perspective of JSEP, it is a typical= answer with a=3Dsendrecv.

Does this sound right to you? If so, I agree we can pro= bably do away with PRANSWER, unless others see something that we're ove= rlooking.
--00235429d374c376c004b92a0eca-- From Jim.Barnett@genesyslab.com Fri Feb 17 08:10:08 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 CAD6921F887F for ; Fri, 17 Feb 2012 08:10:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.213 X-Spam-Level: X-Spam-Status: No, score=-2.213 tagged_above=-999 required=5 tests=[AWL=-0.215, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_83=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 Ot6PNEtO-ebu for ; Fri, 17 Feb 2012 08:10:06 -0800 (PST) Received: from relay-out1.dc.genesyslab.com (relay-out1.dc.genesyslab.com [198.49.180.220]) by ietfa.amsl.com (Postfix) with ESMTP id DA16F21F8876 for ; Fri, 17 Feb 2012 08:10:06 -0800 (PST) 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 q1HGA4Lm012097; Fri, 17 Feb 2012 08:10:04 -0800 (PST) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 17 Feb 2012 08:10:04 -0800 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_01CCED8E.9C02FA50" Date: Fri, 17 Feb 2012 08:09:56 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Joint JSEP draft posted Thread-Index: Aczsb2rl1sLgf07jSo6ppL4n3VodPwBHrNGQ References: From: "Jim Barnett" To: "Justin Uberti" , , X-OriginalArrivalTime: 17 Feb 2012 16:10:04.0491 (UTC) FILETIME=[9BFA41B0:01CCED8E] Cc: "Cullen Jennings \(fluffy\)" Subject: Re: [rtcweb] Joint JSEP draft posted 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, 17 Feb 2012 16:10:08 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCED8E.9C02FA50 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBpcyBqdXN0IGEgZGV0YWlsLCBidXQgSSBoYXZlIGEgcXVlc3Rpb24gYWJvdXQgdGhlIHNh bXBsZSBhcHAgaW4gc2VjdGlvbiA4LiAgSeKAmW0gd29uZGVyaW5nIGFib3V0IHRoZSBmb2xsb3dp bmcgY2FsbCB0byBtYXliZVNpZ25hbCAoKQ0KDQogDQoNCiAgIG5hdmlnYXRvci53ZWJraXRHZXRV c2VyTWVkaWEoDQoNCiAgICAgICAgICAgeyJhdWRpbyI6IHRydWUsICJ2aWRlbyI6IHRydWV9LCBm dW5jdGlvbiAobG9jYWxTdHJlYW0pIHsNCg0KICAgICAgIHNlbGZWaWV3LnNyYyA9IHdlYmtpdFVS TC5jcmVhdGVPYmplY3RVUkwobG9jYWxTdHJlYW0pOw0KDQogICAgICAgcGMuYWRkU3RyZWFtKGxv Y2FsU3RyZWFtKTsNCg0KICAgICAgIG1heWJlU2lnbmFsKGlzQ2FsbGVyKTsNCg0KICAgICB9DQoN CkFzIEkgcmVhZCB0aGUgY29kZSBpbiBib3RoIHRoZSBvZmZlcmVyIGFuZCB0aGUgYW5zd2VyZXIg Y2FzZXMsICBzdGFydElDRSgpIHdpbGwgbm90IGhhdmUgYmVlbiBjYWxsZWQgeWV0LCBzbyBoYXND YW5kaWRhdGVzIHdpbGwgYmUgZmFsc2UgYW5kIG1heWJlU2lnbmFsIHdpbGwgcmV0dXJuIGltbWVk aWF0ZWx5IHdpdGhvdXQgZG9pbmcgYW55dGhpbmcuICBBbSBJIG1pc3Npbmcgc29tZXRoaW5nPw0K DQogDQoNCi0gICAgICAgICAgSmltDQoNCiANCg0KRnJvbTogcnRjd2ViLWJvdW5jZXNAaWV0Zi5v cmcgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEp1c3RpbiBV YmVydGkNClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAxNiwgMjAxMiAxMjo1NCBBTQ0KVG86IHB1 YmxpYy13ZWJydGNAdzMub3JnOyBydGN3ZWJAaWV0Zi5vcmcNCkNjOiBDdWxsZW4gSmVubmluZ3Mg KGZsdWZmeSkNClN1YmplY3Q6IFtydGN3ZWJdIEpvaW50IEpTRVAgZHJhZnQgcG9zdGVkDQoNCiAN Cg0KSSd2ZSBqdXN0IHVwbG9hZGVkIGEgLTAyIHZlcnNpb24gb2YgdGhlIEpTRVAgZHJhZnQsIHRv IHdoaWNoIEN1bGxlbiBKZW5uaW5ncyBoYXMgYWdyZWVkIHRvIHNpZ24gb24gYXMgYSBjby1hdXRo b3IuIFRoaXMgZHJhZnQgaW5jbHVkZXMgYSBmZXcgc3BlY2lmaWMgY2hhbmdlcyBzdWdnZXN0ZWQg YnkgQ3VsbGVuIHRvIGVuc3VyZSB0aGF0IEpTRVAgY2FuIGJlIHVzZWQgdG8gY3JlYXRlIGFwcGxp Y2F0aW9ucyB0aGF0IGFyZSBSRkMgMzI2NC1jb21wbGlhbnQsIGlmIGRlc2lyZWQuIA0KDQogDQoN ClRoZSBkcmFmdCBpcyBhdmFpbGFibGUgYXQgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtdWJlcnRpLXJ0Y3dlYi1qc2VwLTAyLiBQbGVhc2UgcmVmZXIgdG8gdGhpcyBsYXRlc3QgdmVy c2lvbiBvZiB0aGUgZG9jdW1lbnQgd2hlbiByZXNwb25kaW5nIHRvIHRoZSBKU0VQIGNhbGwgZm9y IGNvbnNlbnN1cy4NCg0KIA0KDQpCZXN0IHJlZ2FyZHMsDQoNCi0tanVzdGluDQoNCiANCg0K ------_=_NextPart_001_01CCED8E.9C02FA50 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDggMyA0O30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6Ik1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4 IDMgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiXEBNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAzIDQ7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywg c3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs aW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3Jh cGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJn aW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1h cmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4w cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkVtYWls U3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5IVE1MUHJlZm9y bWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJ bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRl ZCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxp c3QgbDANCgl7bXNvLWxpc3QtaWQ6MTEyNTU0MzA2NDsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsN Cgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTA1NDEzNzEyMCA0MzU4NzI5MjYgNjc2OTg2OTEgNjc2 OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2 OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDo4MDI7DQoJbXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1z by1mYXJlYXN0LWZvbnQtZmFtaWx5OiJNUyBNaW5jaG8iOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21h cmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxp bms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPlRoaXMgaXMganVzdCBhIGRldGFpbCwgYnV0IEkgaGF2ZSBhIHF1 ZXN0aW9uIGFib3V0IHRoZSBzYW1wbGUgYXBwIGluIHNlY3Rpb24gOC7CoCBJ4oCZbSB3b25kZXJp bmcgYWJvdXQgdGhlIGZvbGxvd2luZyBjYWxsIHRvIG1heWJlU2lnbmFsICgpPG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+wqDCoCBuYXZpZ2F0b3Iu d2Via2l0R2V0VXNlck1lZGlhKDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Iic+wqDCoMKgwqDCoMKgwqDCoMKgwqAgeyZxdW90O2F1ZGlvJnF1b3Q7OiB0cnVlLCAmcXVvdDt2 aWRlbyZxdW90OzogdHJ1ZX0sIGZ1bmN0aW9uIChsb2NhbFN0cmVhbSkgezxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+wqDCoMKgwqDCoMKgIHNlbGZWaWV3LnNyYyA9IHdl YmtpdFVSTC5jcmVhdGVPYmplY3RVUkwobG9jYWxTdHJlYW0pOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Iic+wqDCoMKgwqDCoMKgIHBjLmFkZFN0cmVhbShsb2NhbFN0cmVh bSk7PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz7CoMKgwqDCoMKgwqAg bWF5YmVTaWduYWwoaXNDYWxsZXIpOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Iic+wqDCoMKgwqAgfTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjojMUY0OTdEJz5BcyBJIHJlYWQgdGhlIGNvZGUgaW4gYm90aCB0aGUgb2Zm ZXJlciBhbmQgdGhlIGFuc3dlcmVyIGNhc2VzLMKgIHN0YXJ0SUNFKCkgd2lsbCBub3QgaGF2ZSBi ZWVuIGNhbGxlZCB5ZXQsIHNvIGhhc0NhbmRpZGF0ZXMgd2lsbCBiZSBmYWxzZSBhbmQgbWF5YmVT aWduYWwgd2lsbCByZXR1cm4gaW1tZWRpYXRlbHkgd2l0aG91dCBkb2luZyBhbnl0aGluZy7CoCBB bSBJIG1pc3Npbmcgc29tZXRoaW5nPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0ndGV4dC1pbmRlbnQ6LS4yNWluO21zby1s aXN0OmwwIGxldmVsMSBsZm8xJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPi08c3BhbiBzdHlsZT0nZm9udDo3 LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPkppbTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi VGFob21hIiwic2Fucy1zZXJpZiInPiBydGN3ZWItYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnJ0 Y3dlYi1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YgPC9iPkp1c3RpbiBVYmVydGk8 YnI+PGI+U2VudDo8L2I+IFRodXJzZGF5LCBGZWJydWFyeSAxNiwgMjAxMiAxMjo1NCBBTTxicj48 Yj5Ubzo8L2I+IHB1YmxpYy13ZWJydGNAdzMub3JnOyBydGN3ZWJAaWV0Zi5vcmc8YnI+PGI+Q2M6 PC9iPiBDdWxsZW4gSmVubmluZ3MgKGZsdWZmeSk8YnI+PGI+U3ViamVjdDo8L2I+IFtydGN3ZWJd IEpvaW50IEpTRVAgZHJhZnQgcG9zdGVkPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+SSd2 ZSBqdXN0IHVwbG9hZGVkIGEgLTAyIHZlcnNpb24gb2YgdGhlIEpTRVAgZHJhZnQsIHRvIHdoaWNo IEN1bGxlbiBKZW5uaW5ncyBoYXMgYWdyZWVkIHRvIHNpZ24gb24gYXMgYSBjby1hdXRob3IuIFRo aXMgZHJhZnQgaW5jbHVkZXMgYSBmZXcgc3BlY2lmaWMgY2hhbmdlcyBzdWdnZXN0ZWQgYnkgQ3Vs bGVuIHRvIGVuc3VyZSB0aGF0IEpTRVAgY2FuIGJlIHVzZWQgdG8gY3JlYXRlIGFwcGxpY2F0aW9u cyB0aGF0IGFyZSBSRkMgMzI2NC1jb21wbGlhbnQsIGlmIGRlc2lyZWQuJm5ic3A7PG86cD48L286 cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+VGhlIGRyYWZ0IGlzIGF2YWlsYWJsZSBhdCZuYnNwOzxh IGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXViZXJ0aS1ydGN3ZWItanNl cC0wMiI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdWJlcnRpLXJ0Y3dlYi1qc2Vw LTAyPC9hPi4mbmJzcDtQbGVhc2UgcmVmZXIgdG8gdGhpcyBsYXRlc3QgdmVyc2lvbiBvZiB0aGUg ZG9jdW1lbnQgd2hlbiByZXNwb25kaW5nIHRvIHRoZSBKU0VQIGNhbGwgZm9yIGNvbnNlbnN1cy48 bzpwPjwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5CZXN0IHJlZ2FyZHMsPG86cD48L286cD48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+LS1qdXN0aW48bzpwPjwvbzpwPjwvcD48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48L2Rpdj48 L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1sPg== ------_=_NextPart_001_01CCED8E.9C02FA50-- From bernard_aboba@hotmail.com Fri Feb 17 08:24: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 998EA21F8866 for ; Fri, 17 Feb 2012 08:24:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.442 X-Spam-Level: X-Spam-Status: No, score=-101.442 tagged_above=-999 required=5 tests=[AWL=-1.303, BAYES_20=-0.74, HTML_MESSAGE=0.001, J_CHICKENPOX_18=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TiTJgvW+jCW0 for ; Fri, 17 Feb 2012 08:24:45 -0800 (PST) Received: from blu0-omc1-s18.blu0.hotmail.com (blu0-omc1-s18.blu0.hotmail.com [65.55.116.29]) by ietfa.amsl.com (Postfix) with ESMTP id 0428421F8786 for ; Fri, 17 Feb 2012 08:24:44 -0800 (PST) Received: from BLU152-W20 ([65.55.116.8]) by blu0-omc1-s18.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 17 Feb 2012 08:24:44 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_2513627e-e2ce-4ae3-bc37-79f65f108927_" X-Originating-IP: [76.22.61.46] From: Bernard Aboba To: Date: Fri, 17 Feb 2012 08:24:44 -0800 Importance: Normal In-Reply-To: References: <7F2072F1E0DE894DA4B517B93C6A05852C3D87E060@ESESSCMS0356.eemea.ericsson.se>, , <7F2072F1E0DE894DA4B517B93C6A05852C3D8C5AD8@ESESSCMS0356.eemea.ericsson.se>, MIME-Version: 1.0 X-OriginalArrivalTime: 17 Feb 2012 16:24:44.0473 (UTC) FILETIME=[A87CDA90:01CCED90] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] JSEP-01: SDP_PRANSWER and FEDEX use-case 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, 17 Feb 2012 16:24:45 -0000 --_2513627e-e2ce-4ae3-bc37-79f65f108927_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Justin said: "When I say "consent" here=2C I mean the user has given permission to start= transmitting their media (i.e.=2C "answered the call"). This is distinct f= rom the ICE-level "sending media to the right place" mechanisms.=20 Anyway=2C I went and looked at sendonly/recvonly/inactive handling and I th= ink I understand what you are suggesting. Let me see if I can distill this = into some rules:- createOffer/Answer generates a=3Dsendrecv offers/answers = by default. - Installing an a=3Dsendonly/sendrecv description as an answer (via setLoca= lDescription or setRemoteDescription) causes the browser to start sending m= edia from attached streams.- Installing an a=3Drecvonly/sendrecv descriptio= n as an answer (via setLocalDescription or setRemoteDescription) causes the= browser to start playing out received media. - Multiple answers can be received=3B the most recent answer is the one tha= t is used. Which allow for these scenarios:- If an application wants to send an early = response=2C but not start sending/receving media (i.e. it is simply for fas= ter call setup)=2C it can create=2C apply=2C and send an a=3Dinactive answe= r. - When that application sends its final response=2C indicating it wants to = send/receive media=2C it can apply/send an a=3Dsendrecv answer.- In the 1-8= 00-FEDEX case=2C the answer received from 1-800-FEDEX may be a "early respo= nse"=2C but from the perspective of JSEP=2C it is a typical answer with a= =3Dsendrecv. Does this sound right to you? If so=2C I agree we can probably do away with= PRANSWER=2C unless others see something that we're overlooking." [BA] Yes=2C this does sound right to me. With send/receive handling we sho= uld be covered for the Fedex case without a need for PRANSWER.=20 = --_2513627e-e2ce-4ae3-bc37-79f65f108927_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Justin said:

"Whe= n I say "consent" here=2C I mean the user has given permission to start tra= nsmitting their media (i.e.=2C "answered the call"). This is distinct from = the ICE-level "sending media to the right place" mechanisms. =3B

Anyway=2C I went and looked at sendonly/recvonly/inacti= ve handling and I think I understand what you are suggesting. Let me see if= I can distill this into some rules:
- createOffer/Answer generat= es a=3Dsendrecv offers/answers by default.
- Installing an a=3Dsendonly/sendrecv description as an answer (via se= tLocalDescription or setRemoteDescription) causes the browser to start send= ing media from attached streams.
- Installing an a=3Drecvonly/sen= drecv description as an answer (via setLocalDescription or setRemoteDescrip= tion) causes the browser to start playing out received media.
- Multiple answers can be received=3B the most recent answer is the on= e that is used.

Which allow for these scenarios:
- If an application wants to send an early response=2C but not sta= rt sending/receving media (i.e. it is simply for faster call setup)=2C it c= an create=2C apply=2C and send an a=3Dinactive answer.
- When that application sends its final response=2C indicating it want= s to send/receive media=2C it can apply/send an a=3Dsendrecv answer.
<= div>- In the 1-800-FEDEX case=2C the answer received from 1-800-FEDEX may b= e a "early response"=2C but from the perspective of JSEP=2C it is a typical= answer with a=3Dsendrecv.

Does this sound right to you? If so=2C I agree we can p= robably do away with PRANSWER=2C unless others see something that we're ove= rlooking."


[BA] Yes=2C this does sound right to me. =3B With= send/receive handling we should be covered for the Fedex case without a ne= ed for PRANSWER.


= --_2513627e-e2ce-4ae3-bc37-79f65f108927_-- From fluffy@iii.ca Fri Feb 17 12:59: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 9156721F85D2 for ; Fri, 17 Feb 2012 12:59:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.83 X-Spam-Level: X-Spam-Status: No, score=-2.83 tagged_above=-999 required=5 tests=[AWL=-0.231, 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 SJOQ8dlOHXS0 for ; Fri, 17 Feb 2012 12:59:32 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 139A321F85C9 for ; Fri, 17 Feb 2012 12:59:24 -0800 (PST) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5330822E253; Fri, 17 Feb 2012 15:59:17 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E31202EDA663@MCHP058A.global-ad.net> Date: Fri, 17 Feb 2012 13:59:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <15CD1ECE-6BDD-4EE0-AA5B-EF40616578CD@iii.ca> References: <7F2072F1E0DE894DA4B517B93C6A05852C3D87E060@ESESSCMS0356.eemea.ericsson.se> <3CBDF06F-F52D-4C09-A78F-1A0D8479572A@iii.ca> <7F2072F1E0DE894DA4B517B93C6A05852C3D87E58F@ESESSCMS0356.eemea.ericsson.se> <101C6067BEC68246B0C3F6843BCCC1E31202EDA663@MCHP058A.global-ad.net> To: "Hutton, Andrew" X-Mailer: Apple Mail (2.1084) Cc: "public-webrtc@w3.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case 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, 17 Feb 2012 20:59:32 -0000 On Feb 16, 2012, at 1:04 PM, Hutton, Andrew wrote: >> (Also, in the FEDEX case, there could be scenarios where the browser >> does need to transit media, if the user is e.g. promted for DTMFs, >> voice commands etc...) >>=20 >=20 > [AndyH] - I agree that media transmission is required at this stage so = that the user can navigate through voice prompts (E.g. via DTMF) I = thought this was the main requirement from the FEDEX use case. that's not my understanding. My understanding was it was one way media = until the final response in the early media case. And the IVR sends the = first prompt as ringtone but cuts over before two way media (IE DTMF) is = needed. The whole point of this hack is to cut the time the IVR gets = billed for but the SP is not going to provide two way media before = billing starts.=20 From fluffy@iii.ca Fri Feb 17 13: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 C614B11E8079 for ; Fri, 17 Feb 2012 13:21:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.824 X-Spam-Level: X-Spam-Status: No, score=-2.824 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 su6VN+NfUEhs for ; Fri, 17 Feb 2012 13:21:23 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 0B33111E8076 for ; Fri, 17 Feb 2012 13:21:23 -0800 (PST) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 446AE22E253; Fri, 17 Feb 2012 16:21:21 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Fri, 17 Feb 2012 14:21:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <935E62D2-61EB-4E53-98D7-E2BC78AC0B41@iii.ca> References: <387F9047F55E8C42850AD6B3A7A03C6C0E03F8A4@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E03FAB5@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E03FB7C@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E03FC20@inba-mail01.sonusnet.com> <9ED4A9AC-37C7-4E6D-B6C6-4D3C9537B356@iii.ca> <387F9047F55E8C42850AD6B3A7A03C6C0E040130@inba-mail01.sonusnet.com> To: Justin Uberti X-Mailer: Apple Mail (2.1084) Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] Single offer with multiple answer handling in JSEP [was RE: New JSEP draft posted] 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, 17 Feb 2012 21:21:24 -0000 I'm most interested in real world use cases which if they were being = done with SIP would result in multiple 200 being processed by the = browser. I have not got my head around why this would be needed yet and = without the use cases I'm having a hard time deciding if there is a = problem or not.=20 On Feb 16, 2012, at 7:35 PM, Justin Uberti wrote: > Agree it has not been addressed. I'm having some trouble understanding = the exact flows that we need to address here (multiple 2xx, multiple 18x = followed by 2xx, multiple 18x followed by multiple 2xx) but if I = understand correctly your suggestion was: >=20 > 1) allow a setRemoteDesc(SDP_ANSWER) to follow a = setRemoteDesc(SDP_ANSWER) > 2) document that in this case (multiple 2xx), the JS is responsible = for sending BYE to the previous answerer. >=20 > which sounds totally reasonable to me.=20 >=20 > If this sounds good to you, would you mind sketching out a call flow = that I could include in the examples section? >=20 > On Thu, Feb 16, 2012 at 2:11 AM, Ravindran, Parthasarathi = wrote: > Cullen/Justin, >=20 > Single offer with multiple answer open item is not addressed in -02 = version of JSEP draft. Hope you first agree this as an open item in = JSEP. >=20 > Thanks > Partha >=20 > >-----Original Message----- > >From: Ravindran, Parthasarathi > >Sent: Wednesday, February 15, 2012 2:43 PM > >To: 'Cullen Jennings' > >Cc: Justin Uberti; rtcweb@ietf.org; public-webrtc@w3.org > >Subject: RE: [rtcweb] Single offer with multiple answer handling in = JSEP > >[was RE: New JSEP draft posted] > > > >Cullen, > > > >RFC3261 references for receiving multiple 2xx in UAC which does not = fork > >INVITE are as follows: > > > > > >Sec 13.1 Para 3: > > > >Therefore, when multiple 2xx responses are received from different > >remote UAs (because the INVITE forked), each 2xx establishes a = different > >dialog. All these dialogs are part of the same call. > > > >Sec 13.2.2.4 2xx Responses > > > > Multiple 2xx responses may arrive at the UAC for a single INVITE > > request due to a forking proxy. Each response is distinguished by > > the tag parameter in the To header field, and each represents a > > distinct dialog, with a distinct dialog identifier. > > > > If, after acknowledging any 2xx response to an INVITE, the UAC = does > > not want to continue with that dialog, then the UAC MUST terminate > > the dialog by sending a BYE request as described in Section 15. > > > > > >As per the last statements, it is upto the SIP application to decide > >which one of the final 2xx response has to be included within the = call. > >The usecase 3 is based on RFC3262 (PRACK) support wherein it is = possible > >to receive multiple forked 18x with SDP followed by 2xx with or = without > >SDP and SIP 2xx response is not tied to offer/answer exchange. > > > >I have provided mobile to desktop as an example to justify the last > >answer may be used in the offer in some JS application. As I = mentioned > >below, there is no need to restrict updating latest answer for an = offer > >in terms of API and protocol. > > > >Thanks > >Partha > > > >>-----Original Message----- > >>From: Cullen Jennings [mailto:fluffy@iii.ca] > >>Sent: Wednesday, February 15, 2012 1:31 PM > >>To: Ravindran, Parthasarathi > >>Cc: Justin Uberti; rtcweb@ietf.org; public-webrtc@w3.org > >>Subject: Re: [rtcweb] Single offer with multiple answer handling in > >>JSEP [was RE: New JSEP draft posted] > >> > >> > >>I'm a bit lost on use case in SIP context - assuming that the UAC = did > >>not fork but that a proxy or B2BUA did the forking, it seems like = the > >>UAC should never receive more than one final response. > >> > >>In the case of moving from desktop to mobile, it seems like that is > >>updating the stream and would use a call flow more like update = examples > >>in the draft instead of trying to reuse some old answer. > >> > >> > >>On Feb 14, 2012, at 11:24 , Ravindran, Parthasarathi wrote: > >> > >>> Justin, > >>> > >>> Some of the usecases could be > >>> 1) The same user of a website signed-in in the multiples = devices > >>and acts as answerer, the session establishment request to the > >>identity will alert all the signed-in devices and it is possible = that > >>multiple devices answer to the session. Here, user may move from one > >>device > >>(mobile) to another device (desktop) within the session and wishes = to > >>continue the session with the last answer. Please note that website = is > >>flexible to provide this service. > >>> 2) RFC 3261 SIP UA offer/answer handling w.r.t INVITE with = SDP > >to > >>multiple 2xx with SDP handling scenario using JSEP > >>> 3) Another SIP usecase could be multiple 18x responses with = SDP > >>for INVITE with SDP and multiple 2xx responses without SDP but order > >>within 18x and 200 are not same. Say 2xx of the second 18x is = received > >>as the first 2xx. Here, we need to know how second 18x is handled = and > >>also, the subsequent 2xx is handled. > >>> > >>> Of course, it is possible to build more usecases around this area. = As > >>we made signaling outside the scope of WebRTC, it is upto JS > >>application to decide the order in which offer/answer happens. I'm = not > >>relating offer/answer FSM with session establishment state like 18x, > >>2xx but I'm interested in knowing browser media plane behavior in > >>different state of offer/answer handling by which JS application > >>behaves consistently in all browsers. > >>> > >>> Thanks > >>> Partha > >>> > >>> > >>> From: Justin Uberti [mailto:juberti@google.com] > >>> Sent: Tuesday, February 14, 2012 11:36 PM > >>> To: Ravindran, Parthasarathi > >>> Cc: rtcweb@ietf.org; public-webrtc@w3.org > >>> Subject: Re: Single offer with multiple answer handling in JSEP = [was > >>RE: [rtcweb] New JSEP draft posted] > >>> > >>> Partha, > >>> > >>> I need more information about the use case to provide an accurate > >>response. As mentioned in my earlier mail, are both answers 2xx > >>responses? > >>> > >>> On Tue, Feb 14, 2012 at 12:17 PM, Ravindran, Parthasarathi > >> wrote: > >>> Hi Justin, > >>> > >>> In this mail thread, Let us define the behavior of multiple = (atleast > >>two) answers for the single offer in WebRTC browser. Now, Please = let > >>me know your opinion for my below mail. > >>> > >>> Thanks > >>> Partha > >>> > >>> From: Justin Uberti [mailto:juberti@google.com] > >>> Sent: Tuesday, February 14, 2012 9:47 PM > >>> > >>> To: Ravindran, Parthasarathi > >>> Cc: rtcweb@ietf.org; public-webrtc@w3.org > >>> Subject: Re: Single offer with multiple answer handling in JSEP = [was > >>RE: [rtcweb] New JSEP draft posted] > >>> > >>> > >>> > >>> On Tue, Feb 14, 2012 at 6:39 AM, Ravindran, Parthasarathi > >> wrote: > >>> Hi Justin, > >>> > >>> It will be good to mention in the JSEP draft that multiple = answers > >>for single offer will not lead to RTP Mixing and WebRTC client acts = as > >>RTP Endpoint. > >>> > >>> Failing the second Answer will be limiting the provision in RFC = 3264 > >>offer/answer itself as RFC 3264 supports single offer with multiple > >>answer. Also, it is better to define the behavior in API rather than > >>putting this scenario in the browser implementation specific. In = simple > >>scenarios (like alerting with one answer, connect with second = answer), > >>replacing the previous ANSWER will be expected behavior. This may = not > >>be desired behavior in case two connect responses from different = WebRTC > >>clients received with different answers but there is no other > >>alternative solution possible without mixing. > >>> > >>> Do you need to support 2 final answers, or would the provisional > >>answer support provided via SDP_PRANSWER work for you? > >>> > >>> IMO, it is better to define it explicitly in JSEP that "latest = ANSWER > >>to the offer will replace the existing answer is the expected = behavior > >>". Also, Please mentioned that JS application is responsible for > >>discarding (terminating) previous ANSWER notification. Please let = me > >>your opinion on this closure. > >>> > >>> Thanks > >>> Partha > >>> > >>> From: Justin Uberti [mailto:juberti@google.com] > >>> Sent: Tuesday, February 14, 2012 7:29 PM > >>> To: Ravindran, Parthasarathi > >>> Cc: rtcweb@ietf.org; public-webrtc@w3.org > >>> Subject: Re: Single offer with multiple answer handling in JSEP = [was > >>RE: [rtcweb] New JSEP draft posted] > >>> > >>> Regarding your previous mail, an ANSWER after an ANSWER would = either > >>fail (if we wanted to simplify), or replace the previous ANSWER > >>(essentially the same as if you had done setLocalDescription(OFFER, > >>localDescription) followed by setRemoteDescription(ANSWER, answer2). > >>> > >>> In no case would it mix the descriptions/media from both answers. > >>> > >>> Other comments inline below. > >>> > >>> On Tue, Feb 14, 2012 at 1:24 AM, Ravindran, Parthasarathi > >> wrote: > >>> Hi Justin, > >>> > >>> Adding to my earlier mail, In case answer2 SDP is updated in = offerer1 > >>browser without notifying answerer1, then answer1 will continue to > >>transmit RTP which may not be desired behavior. IMO, we need to = define > >>this behavior clearly in offerer side. Some of the possible = solutions > >>are > >>> > >>> 1) offerer1 has to send atleast RTCP BYE packets towards > >>answerer1 while accepting the answerer2 SDP. > >>> > >>> 2) Throw callback to clear answer1 SDP towards offererJS. > >>> > >>> > >>> The application which called setRemoteDescription twice should = have > >>the best idea about what is going on, and therefore is responsible = for > >>notifying answerer1 that its answer has been discarded, if it makes > >>sense to do so. No callback should be needed here. > >>> > >>> > >>> Please let me know your opinion here. > >>> > >>> Thanks > >>> Partha > >>> > >>> From: Ravindran, Parthasarathi > >>> Sent: Tuesday, February 14, 2012 12:07 AM > >>> To: 'Justin Uberti'; rtcweb@ietf.org; public-webrtc@w3.org > >>> Subject: Single offer with multiple answer handling in JSEP [was = RE: > >>[rtcweb] New JSEP draft posted] > >>> > >>> Hi Justin, > >>> > >>> In the draft, it is not spelled out explicitly what is the = expected > >>behavior in offerer browser in case multiple answer is received for > >>single offer. Offer/answer exchange in offerer is as follows: > >>> > >>> OffererJS->OffererUA: var offer =3D pc.createOffer(null); > >>> OffererJS->OffererUA: pc.setLocalDescription(SDP_OFFER, offer); > >>> OffererJS->OffererUA: pc.setRemoteDescription(SDP_ANSWER, = answer1); > >>> OffererUA->Answerer1UA: > >>> OffererJS->OffererUA: pc.setRemoteDescription(SDP_ANSWER, = answer2); > >>> OffererUA->Answerer?UA: ? > >>> > >>> My understanding is that "answer2" will update "answer1" in = browser > >>and starting sending/receiving media towards answer2 media IP and = port. > >>Could you please explain the expected behavior in offerer browser > >>whether it updates the media stream based on the last answer or = mixes > >>both answerer. > >>> > >>> Thanks > >>> Partha > >>> > >>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > >>Behalf Of Justin Uberti > >>> Sent: Thursday, February 09, 2012 2:27 AM > >>> To: rtcweb@ietf.org; public-webrtc@w3.org > >>> Subject: [rtcweb] New JSEP draft posted > >>> > >>> Now available at http://www.ietf.org/id/draft-uberti-rtcweb-jsep- > >>01.txt > >>> > >>> Includes changes based on implementation feedback, and I believe = it > >>addresses most of the concerns raised in last week's interim = meetings: > >>> - Initial documentation provided for each API call, and what state > >>changes it causes > >>> - More examples, including a complete basic sample application > >>> - Simplified approach to trickle candidate handling > >>> - Resolved concerns about how to separate SDP attributes into = media / > >>transport > >>> - Provided encapsulation for SDP blobs and ICE candidate lines, in > >>> the > >>event we want to change encodings or provide helper functions for JS > >>> - Provided mechanism for limiting candidates to TURN-only > >>> - Resolved several implementation issues > >>> > >>> I have not yet addressed the non-overlapping codec concern = mentioned > >>in the interim meeting. I think there are ways of handling this = either > >>in the application or the implementation, but I wanted to get this = -01 > >>out first for feedback. > >>> > >>> > >>> > >>> _______________________________________________ > >>> rtcweb mailing list > >>> rtcweb@ietf.org > >>> https://www.ietf.org/mailman/listinfo/rtcweb >=20 >=20 From roman@telurix.com Fri Feb 17 13:43:03 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 E07E111E8076 for ; Fri, 17 Feb 2012 13:43:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.809 X-Spam-Level: X-Spam-Status: No, score=-3.809 tagged_above=-999 required=5 tests=[AWL=1.167, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_INVITATION=-2, 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 wRpNrxbU3Sdo for ; Fri, 17 Feb 2012 13:43:00 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 95AF921F8542 for ; Fri, 17 Feb 2012 13:43:00 -0800 (PST) Received: by dakl33 with SMTP id l33so3857438dak.31 for ; Fri, 17 Feb 2012 13:43:00 -0800 (PST) Received-SPF: pass (google.com: domain of roman@telurix.com designates 10.68.234.8 as permitted sender) client-ip=10.68.234.8; Authentication-Results: mr.google.com; spf=pass (google.com: domain of roman@telurix.com designates 10.68.234.8 as permitted sender) smtp.mail=roman@telurix.com Received: from mr.google.com ([10.68.234.8]) by 10.68.234.8 with SMTP id ua8mr8135087pbc.10.1329514980510 (num_hops = 1); Fri, 17 Feb 2012 13:43:00 -0800 (PST) Received: by 10.68.234.8 with SMTP id ua8mr6547702pbc.10.1329514980397; Fri, 17 Feb 2012 13:43:00 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id p9sm17686514pbb.9.2012.02.17.13.42.58 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 17 Feb 2012 13:42:59 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so4356909pbc.31 for ; Fri, 17 Feb 2012 13:42:58 -0800 (PST) Received-SPF: pass (google.com: domain of roman@telurix.com designates 10.68.237.106 as permitted sender) client-ip=10.68.237.106; Received: from mr.google.com ([10.68.237.106]) by 10.68.237.106 with SMTP id vb10mr35522924pbc.4.1329514978484 (num_hops = 1); Fri, 17 Feb 2012 13:42:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.237.106 with SMTP id vb10mr28757593pbc.4.1329514978460; Fri, 17 Feb 2012 13:42:58 -0800 (PST) Received: by 10.68.202.202 with HTTP; Fri, 17 Feb 2012 13:42:58 -0800 (PST) In-Reply-To: <935E62D2-61EB-4E53-98D7-E2BC78AC0B41@iii.ca> References: <387F9047F55E8C42850AD6B3A7A03C6C0E03F8A4@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E03FAB5@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E03FB7C@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E03FC20@inba-mail01.sonusnet.com> <9ED4A9AC-37C7-4E6D-B6C6-4D3C9537B356@iii.ca> <387F9047F55E8C42850AD6B3A7A03C6C0E040130@inba-mail01.sonusnet.com> <935E62D2-61EB-4E53-98D7-E2BC78AC0B41@iii.ca> Date: Fri, 17 Feb 2012 16:42:58 -0500 Message-ID: From: Roman Shpount To: Cullen Jennings Content-Type: multipart/alternative; boundary=047d7b33cfc003c57e04b92fd436 X-Gm-Message-State: ALoCoQlzlFEsz+9P1xqHV/fqNsvsW46BWydETUyDs4MloXYOf04qbxco6q3ZfVZYkzXrKf+w1Ilg Cc: "public-webrtc@w3.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Single offer with multiple answer handling in JSEP [was RE: New JSEP draft posted] 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, 17 Feb 2012 21:43:03 -0000 --047d7b33cfc003c57e04b92fd436 Content-Type: text/plain; charset=ISO-8859-1 Cullen, Real case would be anything which implements small group calling with caller side mixing. One example, which is typically used, is a sports team contact. There is a SIP URL which is associated with an entire team. A person places a call to the team's SIP URL. Call gets forked to all the members of the team. Some members answer the call. Multiple simultaneous calls are established, with mixing done in the caller user agent. All the team members who answered and the caller are talking to each other. Another example is shared line appearance. SIP URL which belongs to boss calls both bosses and secretary phones. If both peak up, both are placed in a conference (once again with mixing done in the client user agent). This simulates two analog phones connected to the same line. Before anybody starts saying that those examples are limited to traditional telephony and have only a limited applicability, I would suggest to look at GroupMe or a number of other group calling start ups that showed up and managed to create quite a substantial following recently. Two workaround exist to implement small group calling with no forking. One option is to call through a conferencing server. Downside, apart from a need for a conferencing server, is media hair-pin and extra delay on audio path. Another option is to send an invitation for a call to all potential participants, get offers from each participant that is joining the call, create new channel for each offer and send the answer back. Downside of this approach is an extra half a round trip. Both of those options become especially costly if most of the calls are to one party only and only a small portion of calls result in group call. _____________ Roman Shpount On Fri, Feb 17, 2012 at 4:21 PM, Cullen Jennings wrote: > > I'm most interested in real world use cases which if they were being done > with SIP would result in multiple 200 being processed by the browser. I > have not got my head around why this would be needed yet and without the > use cases I'm having a hard time deciding if there is a problem or not. > > > On Feb 16, 2012, at 7:35 PM, Justin Uberti wrote: > > > Agree it has not been addressed. I'm having some trouble understanding > the exact flows that we need to address here (multiple 2xx, multiple 18x > followed by 2xx, multiple 18x followed by multiple 2xx) but if I understand > correctly your suggestion was: > > > > 1) allow a setRemoteDesc(SDP_ANSWER) to follow a > setRemoteDesc(SDP_ANSWER) > > 2) document that in this case (multiple 2xx), the JS is responsible for > sending BYE to the previous answerer. > > > > which sounds totally reasonable to me. > > > > If this sounds good to you, would you mind sketching out a call flow > that I could include in the examples section? > > > > On Thu, Feb 16, 2012 at 2:11 AM, Ravindran, Parthasarathi < > pravindran@sonusnet.com> wrote: > > Cullen/Justin, > > > > Single offer with multiple answer open item is not addressed in -02 > version of JSEP draft. Hope you first agree this as an open item in JSEP. > > > > Thanks > > Partha > > > > >-----Original Message----- > > >From: Ravindran, Parthasarathi > > >Sent: Wednesday, February 15, 2012 2:43 PM > > >To: 'Cullen Jennings' > > >Cc: Justin Uberti; rtcweb@ietf.org; public-webrtc@w3.org > > >Subject: RE: [rtcweb] Single offer with multiple answer handling in JSEP > > >[was RE: New JSEP draft posted] > > > > > >Cullen, > > > > > >RFC3261 references for receiving multiple 2xx in UAC which does not fork > > >INVITE are as follows: > > > > > > > > >Sec 13.1 Para 3: > > > > > >Therefore, when multiple 2xx responses are received from different > > >remote UAs (because the INVITE forked), each 2xx establishes a different > > >dialog. All these dialogs are part of the same call. > > > > > >Sec 13.2.2.4 2xx Responses > > > > > > Multiple 2xx responses may arrive at the UAC for a single INVITE > > > request due to a forking proxy. Each response is distinguished by > > > the tag parameter in the To header field, and each represents a > > > distinct dialog, with a distinct dialog identifier. > > > > > > If, after acknowledging any 2xx response to an INVITE, the UAC does > > > not want to continue with that dialog, then the UAC MUST terminate > > > the dialog by sending a BYE request as described in Section 15. > > > > > > > > >As per the last statements, it is upto the SIP application to decide > > >which one of the final 2xx response has to be included within the call. > > >The usecase 3 is based on RFC3262 (PRACK) support wherein it is possible > > >to receive multiple forked 18x with SDP followed by 2xx with or without > > >SDP and SIP 2xx response is not tied to offer/answer exchange. > > > > > >I have provided mobile to desktop as an example to justify the last > > >answer may be used in the offer in some JS application. As I mentioned > > >below, there is no need to restrict updating latest answer for an offer > > >in terms of API and protocol. > > > > > >Thanks > > >Partha > > > > > >>-----Original Message----- > > >>From: Cullen Jennings [mailto:fluffy@iii.ca] > > >>Sent: Wednesday, February 15, 2012 1:31 PM > > >>To: Ravindran, Parthasarathi > > >>Cc: Justin Uberti; rtcweb@ietf.org; public-webrtc@w3.org > > >>Subject: Re: [rtcweb] Single offer with multiple answer handling in > > >>JSEP [was RE: New JSEP draft posted] > > >> > > >> > > >>I'm a bit lost on use case in SIP context - assuming that the UAC did > > >>not fork but that a proxy or B2BUA did the forking, it seems like the > > >>UAC should never receive more than one final response. > > >> > > >>In the case of moving from desktop to mobile, it seems like that is > > >>updating the stream and would use a call flow more like update examples > > >>in the draft instead of trying to reuse some old answer. > > >> > > >> > > >>On Feb 14, 2012, at 11:24 , Ravindran, Parthasarathi wrote: > > >> > > >>> Justin, > > >>> > > >>> Some of the usecases could be > > >>> 1) The same user of a website signed-in in the multiples devices > > >>and acts as answerer, the session establishment request to the > > >>identity will alert all the signed-in devices and it is possible that > > >>multiple devices answer to the session. Here, user may move from one > > >>device > > >>(mobile) to another device (desktop) within the session and wishes to > > >>continue the session with the last answer. Please note that website is > > >>flexible to provide this service. > > >>> 2) RFC 3261 SIP UA offer/answer handling w.r.t INVITE with SDP > > >to > > >>multiple 2xx with SDP handling scenario using JSEP > > >>> 3) Another SIP usecase could be multiple 18x responses with SDP > > >>for INVITE with SDP and multiple 2xx responses without SDP but order > > >>within 18x and 200 are not same. Say 2xx of the second 18x is received > > >>as the first 2xx. Here, we need to know how second 18x is handled and > > >>also, the subsequent 2xx is handled. > > >>> > > >>> Of course, it is possible to build more usecases around this area. As > > >>we made signaling outside the scope of WebRTC, it is upto JS > > >>application to decide the order in which offer/answer happens. I'm not > > >>relating offer/answer FSM with session establishment state like 18x, > > >>2xx but I'm interested in knowing browser media plane behavior in > > >>different state of offer/answer handling by which JS application > > >>behaves consistently in all browsers. > > >>> > > >>> Thanks > > >>> Partha > > >>> > > >>> > > >>> From: Justin Uberti [mailto:juberti@google.com] > > >>> Sent: Tuesday, February 14, 2012 11:36 PM > > >>> To: Ravindran, Parthasarathi > > >>> Cc: rtcweb@ietf.org; public-webrtc@w3.org > > >>> Subject: Re: Single offer with multiple answer handling in JSEP [was > > >>RE: [rtcweb] New JSEP draft posted] > > >>> > > >>> Partha, > > >>> > > >>> I need more information about the use case to provide an accurate > > >>response. As mentioned in my earlier mail, are both answers 2xx > > >>responses? > > >>> > > >>> On Tue, Feb 14, 2012 at 12:17 PM, Ravindran, Parthasarathi > > >> wrote: > > >>> Hi Justin, > > >>> > > >>> In this mail thread, Let us define the behavior of multiple (atleast > > >>two) answers for the single offer in WebRTC browser. Now, Please let > > >>me know your opinion for my below mail. > > >>> > > >>> Thanks > > >>> Partha > > >>> > > >>> From: Justin Uberti [mailto:juberti@google.com] > > >>> Sent: Tuesday, February 14, 2012 9:47 PM > > >>> > > >>> To: Ravindran, Parthasarathi > > >>> Cc: rtcweb@ietf.org; public-webrtc@w3.org > > >>> Subject: Re: Single offer with multiple answer handling in JSEP [was > > >>RE: [rtcweb] New JSEP draft posted] > > >>> > > >>> > > >>> > > >>> On Tue, Feb 14, 2012 at 6:39 AM, Ravindran, Parthasarathi > > >> wrote: > > >>> Hi Justin, > > >>> > > >>> It will be good to mention in the JSEP draft that multiple answers > > >>for single offer will not lead to RTP Mixing and WebRTC client acts as > > >>RTP Endpoint. > > >>> > > >>> Failing the second Answer will be limiting the provision in RFC 3264 > > >>offer/answer itself as RFC 3264 supports single offer with multiple > > >>answer. Also, it is better to define the behavior in API rather than > > >>putting this scenario in the browser implementation specific. In simple > > >>scenarios (like alerting with one answer, connect with second answer), > > >>replacing the previous ANSWER will be expected behavior. This may not > > >>be desired behavior in case two connect responses from different WebRTC > > >>clients received with different answers but there is no other > > >>alternative solution possible without mixing. > > >>> > > >>> Do you need to support 2 final answers, or would the provisional > > >>answer support provided via SDP_PRANSWER work for you? > > >>> > > >>> IMO, it is better to define it explicitly in JSEP that "latest ANSWER > > >>to the offer will replace the existing answer is the expected behavior > > >>". Also, Please mentioned that JS application is responsible for > > >>discarding (terminating) previous ANSWER notification. Please let me > > >>your opinion on this closure. > > >>> > > >>> Thanks > > >>> Partha > > >>> > > >>> From: Justin Uberti [mailto:juberti@google.com] > > >>> Sent: Tuesday, February 14, 2012 7:29 PM > > >>> To: Ravindran, Parthasarathi > > >>> Cc: rtcweb@ietf.org; public-webrtc@w3.org > > >>> Subject: Re: Single offer with multiple answer handling in JSEP [was > > >>RE: [rtcweb] New JSEP draft posted] > > >>> > > >>> Regarding your previous mail, an ANSWER after an ANSWER would either > > >>fail (if we wanted to simplify), or replace the previous ANSWER > > >>(essentially the same as if you had done setLocalDescription(OFFER, > > >>localDescription) followed by setRemoteDescription(ANSWER, answer2). > > >>> > > >>> In no case would it mix the descriptions/media from both answers. > > >>> > > >>> Other comments inline below. > > >>> > > >>> On Tue, Feb 14, 2012 at 1:24 AM, Ravindran, Parthasarathi > > >> wrote: > > >>> Hi Justin, > > >>> > > >>> Adding to my earlier mail, In case answer2 SDP is updated in offerer1 > > >>browser without notifying answerer1, then answer1 will continue to > > >>transmit RTP which may not be desired behavior. IMO, we need to define > > >>this behavior clearly in offerer side. Some of the possible solutions > > >>are > > >>> > > >>> 1) offerer1 has to send atleast RTCP BYE packets towards > > >>answerer1 while accepting the answerer2 SDP. > > >>> > > >>> 2) Throw callback to clear answer1 SDP towards offererJS. > > >>> > > >>> > > >>> The application which called setRemoteDescription twice should have > > >>the best idea about what is going on, and therefore is responsible for > > >>notifying answerer1 that its answer has been discarded, if it makes > > >>sense to do so. No callback should be needed here. > > >>> > > >>> > > >>> Please let me know your opinion here. > > >>> > > >>> Thanks > > >>> Partha > > >>> > > >>> From: Ravindran, Parthasarathi > > >>> Sent: Tuesday, February 14, 2012 12:07 AM > > >>> To: 'Justin Uberti'; rtcweb@ietf.org; public-webrtc@w3.org > > >>> Subject: Single offer with multiple answer handling in JSEP [was RE: > > >>[rtcweb] New JSEP draft posted] > > >>> > > >>> Hi Justin, > > >>> > > >>> In the draft, it is not spelled out explicitly what is the expected > > >>behavior in offerer browser in case multiple answer is received for > > >>single offer. Offer/answer exchange in offerer is as follows: > > >>> > > >>> OffererJS->OffererUA: var offer = pc.createOffer(null); > > >>> OffererJS->OffererUA: pc.setLocalDescription(SDP_OFFER, offer); > > >>> OffererJS->OffererUA: pc.setRemoteDescription(SDP_ANSWER, answer1); > > >>> OffererUA->Answerer1UA: > > >>> OffererJS->OffererUA: pc.setRemoteDescription(SDP_ANSWER, answer2); > > >>> OffererUA->Answerer?UA: ? > > >>> > > >>> My understanding is that "answer2" will update "answer1" in browser > > >>and starting sending/receiving media towards answer2 media IP and port. > > >>Could you please explain the expected behavior in offerer browser > > >>whether it updates the media stream based on the last answer or mixes > > >>both answerer. > > >>> > > >>> Thanks > > >>> Partha > > >>> > > >>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > > >>Behalf Of Justin Uberti > > >>> Sent: Thursday, February 09, 2012 2:27 AM > > >>> To: rtcweb@ietf.org; public-webrtc@w3.org > > >>> Subject: [rtcweb] New JSEP draft posted > > >>> > > >>> Now available at http://www.ietf.org/id/draft-uberti-rtcweb-jsep- > > >>01.txt > > >>> > > >>> Includes changes based on implementation feedback, and I believe it > > >>addresses most of the concerns raised in last week's interim meetings: > > >>> - Initial documentation provided for each API call, and what state > > >>changes it causes > > >>> - More examples, including a complete basic sample application > > >>> - Simplified approach to trickle candidate handling > > >>> - Resolved concerns about how to separate SDP attributes into media / > > >>transport > > >>> - Provided encapsulation for SDP blobs and ICE candidate lines, in > > >>> the > > >>event we want to change encodings or provide helper functions for JS > > >>> - Provided mechanism for limiting candidates to TURN-only > > >>> - Resolved several implementation issues > > >>> > > >>> I have not yet addressed the non-overlapping codec concern mentioned > > >>in the interim meeting. I think there are ways of handling this either > > >>in the application or the implementation, but I wanted to get this -01 > > >>out first for feedback. > > >>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> 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 > --047d7b33cfc003c57e04b92fd436 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cullen,

Real case would be anything which implements small group cal= ling with caller side mixing.

One example, which is typically used, = is a sports team contact. There is a SIP URL which is associated with an en= tire team. A person places a call to the team's SIP URL. Call gets fork= ed to all the members of the team. Some members answer the call. Multiple s= imultaneous calls are established, with mixing done in the caller user agen= t. All the team members who answered and the caller are talking to each oth= er.

Another example is shared line appearance. SIP URL which belongs to bos= s calls both bosses and secretary phones. If both peak up, both are placed = in a conference (once again with mixing done in the client user agent). Thi= s simulates two analog phones connected to the same line.

Before anybody starts saying that those examples are limited to traditi= onal telephony and have only a limited applicability, I would suggest to lo= ok at GroupMe or a number of other group calling start ups that showed up a= nd managed to create quite a substantial following recently.

Two workaround exist to implement small group calling with no forking. =

One option is to call through a conferencing server. Downside, apar= t from a need for a conferencing server, is media hair-pin and extra delay = on audio path.

Another option is to send an invitation for a call to all potential par= ticipants, get offers from each participant that is joining the call, creat= e new channel for each offer and send the answer back. Downside of this app= roach is an extra half a round trip.

Both of those options become especially costly if most of the calls are= to one party only and only a small portion of calls result in group call.<= br clear=3D"all">_____________
Roman Shpount


On Fri, Feb 17, 2012 at 4:21 PM, Cullen = Jennings <fluffy@iii.= ca> wrote:

I'm most interested in real world use cases which if they were being do= ne with SIP would result in multiple 200 being processed by the browser. I = have not got my head around why this would be needed yet and without the us= e cases I'm having a hard time deciding if there is a problem or not.

On Feb 16, 2012, at 7:35 PM, Justin Uberti wrote:

> Agree it has not been addressed. I'm having some trouble understan= ding the exact flows that we need to address here (multiple 2xx, multiple 1= 8x followed by 2xx, multiple 18x followed by multiple 2xx) but if I underst= and correctly your suggestion was:
>
> 1) allow a setRemoteDesc(SDP_ANSWER) to follow a setRemoteDesc(SDP_ANS= WER)
> 2) document that in this case (multiple 2xx), the JS is responsible fo= r sending BYE to the previous answerer.
>
> which sounds totally reasonable to me.
>
> If this sounds good to you, would you mind sketching out a call flow t= hat I could include in the examples section?
>
> On Thu, Feb 16, 2012 at 2:11 AM, Ravindran, Parthasarathi <pravindran@sonusnet.com> wrote:<= br> > Cullen/Justin,
>
> Single offer with multiple answer open item is not addressed in -02 ve= rsion of JSEP draft. Hope you first agree this as an open item in JSEP.
>
> Thanks
> Partha
>
> >-----Original Message-----
> >From: Ravindran, Parthasarathi
> >Sent: Wednesday, February 15, 2012 2:43 PM
> >To: 'Cullen Jennings'
> >Cc: Justin Uberti; rtcweb@ietf.= org; public-webrtc@w3.org > >Subject: RE: [rtcweb] Single offer with multiple answer handling i= n JSEP
> >[was RE: New JSEP draft posted]
> >
> >Cullen,
> >
> >RFC3261 references for receiving multiple 2xx in UAC which does no= t fork
> >INVITE are as follows:
> >
> ><RFC quote>
> >Sec 13.1 Para 3:
> >
> >Therefore, when multiple 2xx responses are received from different=
> >remote UAs (because the INVITE forked), each 2xx establishes a dif= ferent
> >dialog. =A0All these dialogs are part of the same call.
> >
> >Sec 13.2.2.4 2xx Responses
> >
> > =A0 Multiple 2xx responses may arrive at the UAC for a single INV= ITE
> > =A0 request due to a forking proxy. =A0Each response is distingui= shed by
> > =A0 the tag parameter in the To header field, and each represents= a
> > =A0 distinct dialog, with a distinct dialog identifier.
> >
> > =A0 If, after acknowledging any 2xx response to an INVITE, the UA= C does
> > =A0 not want to continue with that dialog, then the UAC MUST term= inate
> > =A0 the dialog by sending a BYE request as described in Section 1= 5.
> ></RFC quote>
> >
> >As per the last statements, it is upto the SIP application to deci= de
> >which one of the final 2xx response has to be included within the = call.
> >The usecase 3 is based on RFC3262 (PRACK) support wherein it is po= ssible
> >to receive multiple forked 18x with SDP followed by 2xx with or wi= thout
> >SDP and SIP 2xx response is not tied to offer/answer exchange.
> >
> >I have provided mobile to desktop as an example to justify the las= t
> >answer may be used in the offer in some JS application. As I menti= oned
> >below, there is no need to restrict updating latest answer for an = offer
> >in terms of API and protocol.
> >
> >Thanks
> >Partha
> >
> >>-----Original Message-----
> >>From: Cullen Jennings [mailto:fluffy@iii.ca]
> >>Sent: Wednesday, February 15, 2012 1:31 PM
> >>To: Ravindran, Parthasarathi
> >>Cc: Justin Uberti; rtcweb@i= etf.org; public-webrtc@w3.org
> >>Subject: Re: [rtcweb] Single offer with multiple answer handli= ng in
> >>JSEP [was RE: New JSEP draft posted]
> >>
> >>
> >>I'm a bit lost on use case in SIP context - assuming that = the UAC did
> >>not fork but that a proxy or B2BUA did the forking, it seems l= ike the
> >>UAC should never receive more than one final response.
> >>
> >>In the case of moving from desktop to mobile, it seems like th= at is
> >>updating the stream and would use a call flow more like update= examples
> >>in the draft instead of trying to reuse some old answer.
> >>
> >>
> >>On Feb 14, 2012, at 11:24 , Ravindran, Parthasarathi wrote: > >>
> >>> Justin,
> >>>
> >>> Some of the usecases could be
> >>> 1) =A0 =A0 =A0The same user of a website signed-in in the= multiples devices
> >>and acts as answerer, =A0the session establishment request to = the
> >>identity will alert all the signed-in devices and it is possib= le that
> >>multiple devices answer to the session. Here, user may move fr= om one
> >>device
> >>(mobile) to another device (desktop) within the session and wi= shes to
> >>continue the session with the last answer. Please note that we= bsite is
> >>flexible to provide this service.
> >>> 2) =A0 =A0 =A0RFC 3261 SIP UA offer/answer handling w.r.t= INVITE with SDP
> >to
> >>multiple 2xx with SDP handling scenario using JSEP
> >>> 3) =A0 =A0 =A0Another SIP usecase could be multiple 18x r= esponses with SDP
> >>for INVITE with SDP and multiple 2xx responses without SDP but= order
> >>within 18x and 200 are not same. Say 2xx of the second 18x is = received
> >>as the first 2xx. Here, we need to know how second 18x is hand= led and
> >>also, the subsequent 2xx is handled.
> >>>
> >>> Of course, it is possible to build more usecases around t= his area. As
> >>we made signaling outside the scope of WebRTC, it is upto JS > >>application to decide the order in which offer/answer happens.= I'm not
> >>relating offer/answer FSM with session establishment state lik= e 18x,
> >>2xx but I'm interested in knowing browser media plane beha= vior in
> >>different state of offer/answer handling by which JS applicati= on
> >>behaves consistently in all browsers.
> >>>
> >>> Thanks
> >>> Partha
> >>>
> >>>
> >>> From: Justin Uberti [mailto:juberti@google.com]
> >>> Sent: Tuesday, February 14, 2012 11:36 PM
> >>> To: Ravindran, Parthasarathi
> >>> Cc: rtcweb@ietf.org; public-webrtc@w3.org
> >>> Subject: Re: Single offer with multiple answer handling i= n JSEP [was
> >>RE: [rtcweb] New JSEP draft posted]
> >>>
> >>> Partha,
> >>>
> >>> I need more information about the use case to provide an = accurate
> >>response. As mentioned in my earlier mail, are both answers 2x= x
> >>responses?
> >>>
> >>> On Tue, Feb 14, 2012 at 12:17 PM, Ravindran, Parthasarath= i
> >><pravindran@sonu= snet.com> wrote:
> >>> Hi Justin,
> >>>
> >>> In this mail thread, Let us define the behavior of multip= le (atleast
> >>two) answers for the single offer in WebRTC browser. =A0Now, P= lease let
> >>me know your opinion for my below mail.
> >>>
> >>> Thanks
> >>> Partha
> >>>
> >>> From: Justin Uberti [mailto:juberti@google.com]
> >>> Sent: Tuesday, February 14, 2012 9:47 PM
> >>>
> >>> To: Ravindran, Parthasarathi
> >>> Cc: rtcweb@ietf.org; public-webrtc@w3.org
> >>> Subject: Re: Single offer with multiple answer handling i= n JSEP [was
> >>RE: [rtcweb] New JSEP draft posted]
> >>>
> >>>
> >>>
> >>> On Tue, Feb 14, 2012 at 6:39 AM, Ravindran, Parthasarathi=
> >><pravindran@sonu= snet.com> wrote:
> >>> Hi Justin,
> >>>
> >>> It will be good to mention in the JSEP draft =A0that mult= iple answers
> >>for single offer will not lead to RTP Mixing and WebRTC client= acts as
> >>RTP Endpoint.
> >>>
> >>> Failing the second Answer will be limiting the provision = in RFC 3264
> >>offer/answer itself as RFC 3264 supports single offer with mul= tiple
> >>answer. Also, it is better to define the behavior in API rathe= r than
> >>putting this scenario in the browser implementation specific. = In simple
> >>scenarios (like alerting with one answer, connect with second = answer),
> >>replacing the previous ANSWER will be expected behavior. This = may not
> >>be desired behavior in case two connect responses from differe= nt WebRTC
> >>clients received with different answers =A0but there is no oth= er
> >>alternative solution possible without mixing.
> >>>
> >>> Do you need to support 2 final answers, or would the prov= isional
> >>answer support provided via SDP_PRANSWER work for you?
> >>>
> >>> IMO, it is better to define it explicitly in JSEP that &q= uot;latest ANSWER
> >>to the offer will replace the existing answer is the expected = behavior
> >>". Also, Please mentioned that JS application is responsi= ble for
> >>discarding (terminating) previous ANSWER notification. =A0 Ple= ase let me
> >>your opinion on this closure.
> >>>
> >>> Thanks
> >>> Partha
> >>>
> >>> From: Justin Uberti [mailto:juberti@google.com]
> >>> Sent: Tuesday, February 14, 2012 7:29 PM
> >>> To: Ravindran, Parthasarathi
> >>> Cc: rtcweb@ietf.org; public-webrtc@w3.org
> >>> Subject: Re: Single offer with multiple answer handling i= n JSEP [was
> >>RE: [rtcweb] New JSEP draft posted]
> >>>
> >>> Regarding your previous mail, an ANSWER after an ANSWER w= ould either
> >>fail (if we wanted to simplify), or replace the previous ANSWE= R
> >>(essentially the same as if you had done setLocalDescription(O= FFER,
> >>localDescription) followed by setRemoteDescription(ANSWER, ans= wer2).
> >>>
> >>> In no case would it mix the descriptions/media from both = answers.
> >>>
> >>> Other comments inline below.
> >>>
> >>> On Tue, Feb 14, 2012 at 1:24 AM, Ravindran, Parthasarathi=
> >><pravindran@sonu= snet.com> wrote:
> >>> Hi Justin,
> >>>
> >>> Adding to my earlier mail, In case answer2 SDP is updated= in offerer1
> >>browser without notifying answerer1, then answer1 will continu= e to
> >>transmit RTP which may not be desired behavior. IMO, we need t= o define
> >>this behavior clearly in offerer side. Some of the possible so= lutions
> >>are
> >>>
> >>> 1) =A0 =A0 =A0offerer1 has to send atleast RTCP BYE packe= ts towards
> >>answerer1 while accepting the answerer2 SDP.
> >>>
> >>> 2) =A0 =A0 =A0Throw callback to clear answer1 SDP towards= offererJS.
> >>>
> >>>
> >>> The application which called setRemoteDescription twice s= hould have
> >>the best idea about what is going on, and therefore is respons= ible for
> >>notifying answerer1 that its answer has been discarded, if it = makes
> >>sense to do so. No callback should be needed here.
> >>>
> >>>
> >>> Please let me know your opinion here.
> >>>
> >>> Thanks
> >>> Partha
> >>>
> >>> From: Ravindran, Parthasarathi
> >>> Sent: Tuesday, February 14, 2012 12:07 AM
> >>> To: 'Justin Uberti'; rtcweb@ietf.org; public-= webrtc@w3.org
> >>> Subject: Single offer with multiple answer handling in JS= EP [was RE:
> >>[rtcweb] New JSEP draft posted]
> >>>
> >>> Hi Justin,
> >>>
> >>> In the draft, it is not spelled out explicitly what is th= e expected
> >>behavior in offerer browser in case multiple answer is receive= d for
> >>single offer. Offer/answer exchange in offerer is as follows:<= br> > >>>
> >>> OffererJS->OffererUA: var offer =3D pc.createOffer(nul= l);
> >>> OffererJS->OffererUA: pc.setLocalDescription(SDP_OFFER= , offer);
> >>> OffererJS->OffererUA: =A0pc.setRemoteDescription(SDP_A= NSWER, answer1);
> >>> OffererUA->Answerer1UA: <media>
> >>> OffererJS->OffererUA: =A0pc.setRemoteDescription(SDP_A= NSWER, answer2);
> >>> OffererUA->Answerer?UA: <media>?
> >>>
> >>> My understanding is that "answer2" will update = "answer1" in browser
> >>and starting sending/receiving media towards answer2 media IP = and port.
> >>Could you please explain the expected behavior in offerer brow= ser
> >>whether it updates the media stream based on the last answer o= r mixes
> >>both answerer.
> >>>
> >>> Thanks
> >>> Partha
> >>>
> >>> From: rtcweb-b= ounces@ietf.org [mailto:rtcw= eb-bounces@ietf.org] On
> >>Behalf Of Justin Uberti
> >>> Sent: Thursday, February 09, 2012 2:27 AM
> >>> To: rtcweb@ietf.org; public-webrtc@w3.org
> >>> Subject: [rtcweb] New JSEP draft posted
> >>>
> >>> Now available at http://www.ietf.org/id/draft-uberti-= rtcweb-jsep-
> >>01.txt
> >>>
> >>> Includes changes based on implementation feedback, and I = believe it
> >>addresses most of the concerns raised in last week's inter= im meetings:
> >>> - Initial documentation provided for each API call, and w= hat state
> >>changes it causes
> >>> - More examples, including a complete basic sample applic= ation
> >>> - Simplified approach to trickle candidate handling
> >>> - Resolved concerns about how to separate SDP attributes = into media /
> >>transport
> >>> - Provided encapsulation for SDP blobs and ICE candidate = lines, in
> >>> the
> >>event we want to change encodings or provide helper functions = for JS
> >>> - Provided mechanism for limiting candidates to TURN-only=
> >>> - Resolved several implementation issues
> >>>
> >>> I have not yet addressed the non-overlapping codec concer= n mentioned
> >>in the interim meeting. I think there are ways of handling thi= s either
> >>in the application or the implementation, but I wanted to get = this -01
> >>out first for feedback.
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> 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

--047d7b33cfc003c57e04b92fd436-- From snandaku@cisco.com Fri Feb 17 13:50: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 166E421E8044 for ; Fri, 17 Feb 2012 13:50:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.175 X-Spam-Level: X-Spam-Status: No, score=-4.175 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_VALIUM2=2.643, FUZZY_VLIUM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067, SARE_MILLIONSOF=0.315, WEIRD_PORT=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 PwOxJVsrllBo for ; Fri, 17 Feb 2012 13:50:34 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8E18B11E808D for ; Fri, 17 Feb 2012 13:50:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=snandaku@cisco.com; l=9927; q=dns/txt; s=iport; t=1329515433; x=1330725033; h=date:subject:from:to:cc:message-id:mime-version; bh=vCtJjfR2D/fwOYqKcnw0iVjBH3Z19sFc6C+DSu7/tWs=; b=JspBV+oSDe26dLuNPcZdypu5dnjpV7/KKqdsIsNW/0Fd8xJwg/rRGU2Y /Ab3EcMaGwWkLxozwEBvjHu53/0HuedNRqJRXneVVI8XBRCnCzHMG/Rlo pJCzR78dPfpf2ukDJpSfyAvOS/rZaLyDT+CzW/Mrt48zycR2OBhg6zM/E A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQJAHfKPk+tJXG9/2dsb2JhbABEgk2laAGJAGgCgQeBdwEEEgEqPBIBESduAQQOJ4dnmg4BnlmLdQMBAQgKDwMBAQECOwMBBoM8NAomgxwEiBszhRyHTY5HhEI X-IronPort-AV: E=Sophos;i="4.73,440,1325462400"; d="scan'208,217";a="59898837" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 17 Feb 2012 21:50:33 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id q1HLoWtg027995; Fri, 17 Feb 2012 21:50:32 GMT Received: from xmb-rcd-212.cisco.com ([72.163.62.219]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 17 Feb 2012 15:50:32 -0600 Received: from 171.68.20.201 ([171.68.20.201]) by XMB-RCD-212.cisco.com ([72.163.62.219]) with Microsoft Exchange Server HTTP-DAV ; Fri, 17 Feb 2012 21:50:31 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Fri, 17 Feb 2012 13:50:31 -0800 From: snandaku To: "rtcweb@ietf.org" Message-ID: Thread-Topic: URI Scheme for TURN Configuration Thread-Index: Acztvisgg+aSg30roEqjs2l7hTwgaQ== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3412331431_68462247" X-OriginalArrivalTime: 17 Feb 2012 21:50:32.0505 (UTC) FILETIME=[2C05D290:01CCEDBE] Subject: [rtcweb] URI Scheme for TURN Configuration 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, 17 Feb 2012 21:50:37 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3412331431_68462247 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hello All We have submitted a proposal to IETF BEHAVE WG on URI scheme representing TURN configuration. Draft can be retrieved at :( http://tools.ietf.org/html/draft-petithuguenin-behave-turn-uris-00) =20 We presented the idea at the BEHAVE interim today and it was positively received. The BEHAVE chairs were interested in obtaining a signoff on choosing URI scheme against proposals based on string representation or JSON for the matter. We would like to get opinions and thoughts around this approach from RTCWeb/WebRTC chairs and the members. Below we have summarized the motivation and some samples from the draft for a quick reference. Motivation for the TURN URI Scheme in the context of RTCWeb -TURN protocol is used to establish candidates to perform ICE connectivity checks. - Current proposal in the spec based on string representation has inherent shortcomings and is not future proof (say ipv6:port scenarios) - An URI scheme with well defined grammar SHALL help in the following ways Provide UNIVERSAL way to configure TURN Server configuration to myriad of RTCWeb Clients/Web Applications Enhance INTEROPERABILITY between implementations by standardizing on the URI Scheme across Different Browser Vendors, Different Web Application Services, Gateways and alike. Define STANDARD data representation format as enforced by the URI scheme Enable EVOLUTION and FUTURE PROOFING defined by the encoding URI syntax grammar Immediate BENEFITS can be realized from current proposals for things like IPv6 support, Unicode user/password, resolution mechanism, etc. Sample URI=20 turn:example.org turns:example.org:8189 turn:example.org?transport=3Dudp We did think about JSON as one possible approach but didn=B9t pursue further for few reasons mentioned below JSON is nice for web browser (theory), but it=B9s useful to keep in mind that: >> =B7 Just doing an eval on a JSON object is a bad idea, so it has t= o >> be parsed with parsing logic =AD no benefit in terms of processing >> =B7 It=B9s harder for a human to compose a JSON object, but URIs are >> more widely understood >> =B7 JavaScript is the popular language today, but Google and other= s >> will come along with new programming languages (witness: DART) and then >> what? Will JSON be as attractive? I suspect URIs will be. >> =B7 We want this to be useful in places outside the browser, so JS= ON >> should not be the first thought Apart from the above reasons, going with URI scheme will permit to simplify the text in the W3C document by referencin RFC 5928 and the future TURN URI RFC. That cannot be a bad thing. A third motivation is that as the TURN URI is done in a different WG, this permits to do this work in parallel to RTCWEB (that probably does not need more distractions). RTCWeb impacts millions of end-points and we strongly believe providing standard way to provision and configure TURN/STUN information would be really effective. Please let us know your thoughts and support in this approach Regards Suhas Nandakumar Marc Petit Huhuenin Gonzalo Salgueiro Paul E Jones --B_3412331431_68462247 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable URI Scheme for TURN Configuration
Hello All

        We have submitted a proposa= l to IETF BEHAVE WG on URI scheme representing TURN configuration. Draft can= be retrieved at :( http://tools.ietf.org/html/dra= ft-petithuguenin-behave-turn-uris-00)
       
 We presented the idea at the BEHAVE interim today and it was positive= ly received. The BEHAVE chairs were interested in obtaining a signoff on cho= osing  URI scheme against proposals based on string representation or J= SON for the matter. We would like to get opinions and thoughts around this a= pproach from RTCWeb/WebRTC chairs and the members.


    Below we have summarized the motivation and some sa= mples from the draft for a quick reference.

    Motivation for the TURN URI Scheme in the contex= t of RTCWeb
        -TURN protocol is  used= to establish candidates to perform ICE connectivity checks.
        - Current proposal in the s= pec based on string representation has inherent shortcomings and is not futu= re proof (say ipv6:port scenarios)
        - An URI scheme with well d= efined grammar SHALL help in the following ways
            &nb= sp;       Provide UNIVERSAL way to= configure TURN Server configuration to myriad of RTCWeb Clients/Web Applica= tions
            &nb= sp;       Enhance INTEROPERABILITY between implementations by standardizing on the URI Scheme across
            &nb= sp;            &= nbsp;      Different Browser Vendors, Differen= t Web Application Services, Gateways and alike.
            &nb= sp;       Define STANDARD data rep= resentation format as enforced by the URI scheme
            &nb= sp;       Enable EVOLUTION and = FUTURE PROOFING defined by the encoding URI syntax grammar
            &nb= sp;      Immediate  BENEFITS can be re= alized from current proposals for things like IPv6 support, Unicode user= /password,
            &nb= sp;       resolution mechanism, etc. &nbs= p;     

       Sample URI
           &nbs= p;   turn:example.org
            &nb= sp;   turns:example.org:8189
            &nb= sp;   turn:example.org?transport=3Dudp

     We did think about JSON as one possible appro= ach but didn’t pursue further for few reasons mentioned below
            JSO= N is nice for web browser (theory), but it’s useful to keep in mind th= at:
·     &nb= sp;   Just doing an eval on a JSON object is a bad idea, so i= t has to
be parsed with parsing logic – no benefit in terms of processing
·         It’s harder = for a human to compose a JSON object, but URIs are
more widely understood
·         JavaScript is the = popular language today, but Google and others
will come along with new programming languages (witness: DART) and then
what?  Will JSON be as attractive? I suspect URIs will be.
·         We want this to be= useful in places outside the browser, so JSON
should not be the first thought


  Apart from the above reasons, going with URI scheme will permit= to simplify the text in the W3C document by referencin RFC 5928 and the fut= ure TURN URI RFC.  That cannot be a bad thing.  A third motivation= is that as the TURN URI is done in a different WG, this permits to do this = work in parallel to RTCWEB (that probably does not need more distractions).<= BR>
 RTCWeb impacts millions of end-points and we strongly believe providi= ng standard way to provision and configure TURN/STUN information would be re= ally effective.



Please let us know your thoughts and support in this approach




Regards
Suhas Nandakumar
Marc Petit Huhuenin
Gonzalo Salgueiro
Paul E Jones
 --B_3412331431_68462247-- From christer.holmberg@ericsson.com Fri Feb 17 14:36: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 6CA1F11E808D for ; Fri, 17 Feb 2012 14:36:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.834 X-Spam-Level: X-Spam-Status: No, score=-9.834 tagged_above=-999 required=5 tests=[AWL=0.765, 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 EgonQJE3Ccmu for ; Fri, 17 Feb 2012 14:36:49 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 6E89411E80A1 for ; Fri, 17 Feb 2012 14:36:48 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-46-4f3ed67f7e8c Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id D5.0E.01970.F76DE3F4; Fri, 17 Feb 2012 23:36:47 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Fri, 17 Feb 2012 23:36:47 +0100 From: Christer Holmberg To: Cullen Jennings , Justin Uberti Date: Fri, 17 Feb 2012 23:36:46 +0100 Thread-Topic: [rtcweb] Single offer with multiple answer handling in JSEP [was RE: New JSEP draft posted] Thread-Index: AcztuiKk3fcA4c7US8KNkiIVJILlmwACcbHT Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3D31BA2B@ESESSCMS0356.eemea.ericsson.se> References: <387F9047F55E8C42850AD6B3A7A03C6C0E03F8A4@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E03FAB5@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E03FB7C@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E03FC20@inba-mail01.sonusnet.com> <9ED4A9AC-37C7-4E6D-B6C6-4D3C9537B356@iii.ca> <387F9047F55E8C42850AD6B3A7A03C6C0E040130@inba-mail01.sonusnet.com> , <935E62D2-61EB-4E53-98D7-E2BC78AC0B41@iii.ca> In-Reply-To: <935E62D2-61EB-4E53-98D7-E2BC78AC0B41@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-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] Single offer with multiple answer handling in JSEP [was RE: New JSEP draft posted] 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, 17 Feb 2012 22:36:50 -0000 Hi, I can of course only speak for myself, but in all my years of working with = SIP systems I have never encountered a use case where multiple 200 response= s would have to be accepted. In most cases the first 2xx will be accepted, = and any subsequent 2xx will be ACKed+ BYEed. However, from a browser perspective I don't think it matters whether the an= swers are received in 18x responses or 2xx responses. The fact is that mult= iple answers may be received, and the browser needs to be able to handle th= at.=20 And, it seems like people agree that a new answer would replace the old one= , as also suggested by Justin below. And, IF someone wants to establish simultanous dialogs with multiple remote= entities, in my opinion it would then be better to e.g. create multiple Pe= erConnections (one for each remote entity), or something like that. Regards, Christer ________________________________________ From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] On Behalf Of Cullen= Jennings [fluffy@iii.ca] Sent: Friday, February 17, 2012 11:21 PM To: Justin Uberti Cc: rtcweb@ietf.org; public-webrtc@w3.org Subject: Re: [rtcweb] Single offer with multiple answer handling in JSEP = [was RE: New JSEP draft posted] I'm most interested in real world use cases which if they were being done w= ith SIP would result in multiple 200 being processed by the browser. I have= not got my head around why this would be needed yet and without the use ca= ses I'm having a hard time deciding if there is a problem or not. On Feb 16, 2012, at 7:35 PM, Justin Uberti wrote: > Agree it has not been addressed. I'm having some trouble understanding th= e exact flows that we need to address here (multiple 2xx, multiple 18x foll= owed by 2xx, multiple 18x followed by multiple 2xx) but if I understand cor= rectly your suggestion was: > > 1) allow a setRemoteDesc(SDP_ANSWER) to follow a setRemoteDesc(SDP_ANSWER= ) > 2) document that in this case (multiple 2xx), the JS is responsible for s= ending BYE to the previous answerer. > > which sounds totally reasonable to me. > > If this sounds good to you, would you mind sketching out a call flow that= I could include in the examples section? > > On Thu, Feb 16, 2012 at 2:11 AM, Ravindran, Parthasarathi wrote: > Cullen/Justin, > > Single offer with multiple answer open item is not addressed in -02 versi= on of JSEP draft. Hope you first agree this as an open item in JSEP. > > Thanks > Partha > > >-----Original Message----- > >From: Ravindran, Parthasarathi > >Sent: Wednesday, February 15, 2012 2:43 PM > >To: 'Cullen Jennings' > >Cc: Justin Uberti; rtcweb@ietf.org; public-webrtc@w3.org > >Subject: RE: [rtcweb] Single offer with multiple answer handling in JSEP > >[was RE: New JSEP draft posted] > > > >Cullen, > > > >RFC3261 references for receiving multiple 2xx in UAC which does not fork > >INVITE are as follows: > > > > > >Sec 13.1 Para 3: > > > >Therefore, when multiple 2xx responses are received from different > >remote UAs (because the INVITE forked), each 2xx establishes a different > >dialog. All these dialogs are part of the same call. > > > >Sec 13.2.2.4 2xx Responses > > > > Multiple 2xx responses may arrive at the UAC for a single INVITE > > request due to a forking proxy. Each response is distinguished by > > the tag parameter in the To header field, and each represents a > > distinct dialog, with a distinct dialog identifier. > > > > If, after acknowledging any 2xx response to an INVITE, the UAC does > > not want to continue with that dialog, then the UAC MUST terminate > > the dialog by sending a BYE request as described in Section 15. > > > > > >As per the last statements, it is upto the SIP application to decide > >which one of the final 2xx response has to be included within the call. > >The usecase 3 is based on RFC3262 (PRACK) support wherein it is possible > >to receive multiple forked 18x with SDP followed by 2xx with or without > >SDP and SIP 2xx response is not tied to offer/answer exchange. > > > >I have provided mobile to desktop as an example to justify the last > >answer may be used in the offer in some JS application. As I mentioned > >below, there is no need to restrict updating latest answer for an offer > >in terms of API and protocol. > > > >Thanks > >Partha > > > >>-----Original Message----- > >>From: Cullen Jennings [mailto:fluffy@iii.ca] > >>Sent: Wednesday, February 15, 2012 1:31 PM > >>To: Ravindran, Parthasarathi > >>Cc: Justin Uberti; rtcweb@ietf.org; public-webrtc@w3.org > >>Subject: Re: [rtcweb] Single offer with multiple answer handling in > >>JSEP [was RE: New JSEP draft posted] > >> > >> > >>I'm a bit lost on use case in SIP context - assuming that the UAC did > >>not fork but that a proxy or B2BUA did the forking, it seems like the > >>UAC should never receive more than one final response. > >> > >>In the case of moving from desktop to mobile, it seems like that is > >>updating the stream and would use a call flow more like update examples > >>in the draft instead of trying to reuse some old answer. > >> > >> > >>On Feb 14, 2012, at 11:24 , Ravindran, Parthasarathi wrote: > >> > >>> Justin, > >>> > >>> Some of the usecases could be > >>> 1) The same user of a website signed-in in the multiples devices > >>and acts as answerer, the session establishment request to the > >>identity will alert all the signed-in devices and it is possible that > >>multiple devices answer to the session. Here, user may move from one > >>device > >>(mobile) to another device (desktop) within the session and wishes to > >>continue the session with the last answer. Please note that website is > >>flexible to provide this service. > >>> 2) RFC 3261 SIP UA offer/answer handling w.r.t INVITE with SDP > >to > >>multiple 2xx with SDP handling scenario using JSEP > >>> 3) Another SIP usecase could be multiple 18x responses with SDP > >>for INVITE with SDP and multiple 2xx responses without SDP but order > >>within 18x and 200 are not same. Say 2xx of the second 18x is received > >>as the first 2xx. Here, we need to know how second 18x is handled and > >>also, the subsequent 2xx is handled. > >>> > >>> Of course, it is possible to build more usecases around this area. As > >>we made signaling outside the scope of WebRTC, it is upto JS > >>application to decide the order in which offer/answer happens. I'm not > >>relating offer/answer FSM with session establishment state like 18x, > >>2xx but I'm interested in knowing browser media plane behavior in > >>different state of offer/answer handling by which JS application > >>behaves consistently in all browsers. > >>> > >>> Thanks > >>> Partha > >>> > >>> > >>> From: Justin Uberti [mailto:juberti@google.com] > >>> Sent: Tuesday, February 14, 2012 11:36 PM > >>> To: Ravindran, Parthasarathi > >>> Cc: rtcweb@ietf.org; public-webrtc@w3.org > >>> Subject: Re: Single offer with multiple answer handling in JSEP [was > >>RE: [rtcweb] New JSEP draft posted] > >>> > >>> Partha, > >>> > >>> I need more information about the use case to provide an accurate > >>response. As mentioned in my earlier mail, are both answers 2xx > >>responses? > >>> > >>> On Tue, Feb 14, 2012 at 12:17 PM, Ravindran, Parthasarathi > >> wrote: > >>> Hi Justin, > >>> > >>> In this mail thread, Let us define the behavior of multiple (atleast > >>two) answers for the single offer in WebRTC browser. Now, Please let > >>me know your opinion for my below mail. > >>> > >>> Thanks > >>> Partha > >>> > >>> From: Justin Uberti [mailto:juberti@google.com] > >>> Sent: Tuesday, February 14, 2012 9:47 PM > >>> > >>> To: Ravindran, Parthasarathi > >>> Cc: rtcweb@ietf.org; public-webrtc@w3.org > >>> Subject: Re: Single offer with multiple answer handling in JSEP [was > >>RE: [rtcweb] New JSEP draft posted] > >>> > >>> > >>> > >>> On Tue, Feb 14, 2012 at 6:39 AM, Ravindran, Parthasarathi > >> wrote: > >>> Hi Justin, > >>> > >>> It will be good to mention in the JSEP draft that multiple answers > >>for single offer will not lead to RTP Mixing and WebRTC client acts as > >>RTP Endpoint. > >>> > >>> Failing the second Answer will be limiting the provision in RFC 3264 > >>offer/answer itself as RFC 3264 supports single offer with multiple > >>answer. Also, it is better to define the behavior in API rather than > >>putting this scenario in the browser implementation specific. In simple > >>scenarios (like alerting with one answer, connect with second answer), > >>replacing the previous ANSWER will be expected behavior. This may not > >>be desired behavior in case two connect responses from different WebRTC > >>clients received with different answers but there is no other > >>alternative solution possible without mixing. > >>> > >>> Do you need to support 2 final answers, or would the provisional > >>answer support provided via SDP_PRANSWER work for you? > >>> > >>> IMO, it is better to define it explicitly in JSEP that "latest ANSWER > >>to the offer will replace the existing answer is the expected behavior > >>". Also, Please mentioned that JS application is responsible for > >>discarding (terminating) previous ANSWER notification. Please let me > >>your opinion on this closure. > >>> > >>> Thanks > >>> Partha > >>> > >>> From: Justin Uberti [mailto:juberti@google.com] > >>> Sent: Tuesday, February 14, 2012 7:29 PM > >>> To: Ravindran, Parthasarathi > >>> Cc: rtcweb@ietf.org; public-webrtc@w3.org > >>> Subject: Re: Single offer with multiple answer handling in JSEP [was > >>RE: [rtcweb] New JSEP draft posted] > >>> > >>> Regarding your previous mail, an ANSWER after an ANSWER would either > >>fail (if we wanted to simplify), or replace the previous ANSWER > >>(essentially the same as if you had done setLocalDescription(OFFER, > >>localDescription) followed by setRemoteDescription(ANSWER, answer2). > >>> > >>> In no case would it mix the descriptions/media from both answers. > >>> > >>> Other comments inline below. > >>> > >>> On Tue, Feb 14, 2012 at 1:24 AM, Ravindran, Parthasarathi > >> wrote: > >>> Hi Justin, > >>> > >>> Adding to my earlier mail, In case answer2 SDP is updated in offerer1 > >>browser without notifying answerer1, then answer1 will continue to > >>transmit RTP which may not be desired behavior. IMO, we need to define > >>this behavior clearly in offerer side. Some of the possible solutions > >>are > >>> > >>> 1) offerer1 has to send atleast RTCP BYE packets towards > >>answerer1 while accepting the answerer2 SDP. > >>> > >>> 2) Throw callback to clear answer1 SDP towards offererJS. > >>> > >>> > >>> The application which called setRemoteDescription twice should have > >>the best idea about what is going on, and therefore is responsible for > >>notifying answerer1 that its answer has been discarded, if it makes > >>sense to do so. No callback should be needed here. > >>> > >>> > >>> Please let me know your opinion here. > >>> > >>> Thanks > >>> Partha > >>> > >>> From: Ravindran, Parthasarathi > >>> Sent: Tuesday, February 14, 2012 12:07 AM > >>> To: 'Justin Uberti'; rtcweb@ietf.org; public-webrtc@w3.org > >>> Subject: Single offer with multiple answer handling in JSEP [was RE: > >>[rtcweb] New JSEP draft posted] > >>> > >>> Hi Justin, > >>> > >>> In the draft, it is not spelled out explicitly what is the expected > >>behavior in offerer browser in case multiple answer is received for > >>single offer. Offer/answer exchange in offerer is as follows: > >>> > >>> OffererJS->OffererUA: var offer =3D pc.createOffer(null); > >>> OffererJS->OffererUA: pc.setLocalDescription(SDP_OFFER, offer); > >>> OffererJS->OffererUA: pc.setRemoteDescription(SDP_ANSWER, answer1); > >>> OffererUA->Answerer1UA: > >>> OffererJS->OffererUA: pc.setRemoteDescription(SDP_ANSWER, answer2); > >>> OffererUA->Answerer?UA: ? > >>> > >>> My understanding is that "answer2" will update "answer1" in browser > >>and starting sending/receiving media towards answer2 media IP and port. > >>Could you please explain the expected behavior in offerer browser > >>whether it updates the media stream based on the last answer or mixes > >>both answerer. > >>> > >>> Thanks > >>> Partha > >>> > >>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > >>Behalf Of Justin Uberti > >>> Sent: Thursday, February 09, 2012 2:27 AM > >>> To: rtcweb@ietf.org; public-webrtc@w3.org > >>> Subject: [rtcweb] New JSEP draft posted > >>> > >>> Now available at http://www.ietf.org/id/draft-uberti-rtcweb-jsep- > >>01.txt > >>> > >>> Includes changes based on implementation feedback, and I believe it > >>addresses most of the concerns raised in last week's interim meetings: > >>> - Initial documentation provided for each API call, and what state > >>changes it causes > >>> - More examples, including a complete basic sample application > >>> - Simplified approach to trickle candidate handling > >>> - Resolved concerns about how to separate SDP attributes into media / > >>transport > >>> - Provided encapsulation for SDP blobs and ICE candidate lines, in > >>> the > >>event we want to change encodings or provide helper functions for JS > >>> - Provided mechanism for limiting candidates to TURN-only > >>> - Resolved several implementation issues > >>> > >>> I have not yet addressed the non-overlapping codec concern mentioned > >>in the interim meeting. I think there are ways of handling this either > >>in the application or the implementation, but I wanted to get this -01 > >>out first for feedback. > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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 christer.holmberg@ericsson.com Fri Feb 17 14:43: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 692E711E808D for ; Fri, 17 Feb 2012 14:43:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.855 X-Spam-Level: X-Spam-Status: No, score=-9.855 tagged_above=-999 required=5 tests=[AWL=0.744, 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 uRWu0T2uswQ0 for ; Fri, 17 Feb 2012 14:43:58 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 6E40321F85E5 for ; Fri, 17 Feb 2012 14:43:58 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-2e-4f3ed82d03f5 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 11.6C.27041.D28DE3F4; Fri, 17 Feb 2012 23:43:57 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Fri, 17 Feb 2012 23:43:56 +0100 From: Christer Holmberg To: Cullen Jennings Date: Fri, 17 Feb 2012 23:43:56 +0100 Thread-Topic: [rtcweb] JSEP-01: SDP_PRANSWER and FEDEX use-case Thread-Index: AcztucNJ8xgBb87cQ7yqXBqrT9BvfAACw7a3 Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3D31BA2C@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C3D87E060@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C3D8C5AD8@ESESSCMS0356.eemea.ericsson.se>, <436C38E2-AF52-45FD-9A68-DC78F72DAF64@cisco.com> In-Reply-To: <436C38E2-AF52-45FD-9A68-DC78F72DAF64@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "public-webrtc@w3.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP-01: SDP_PRANSWER and FEDEX use-case 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, 17 Feb 2012 22:43:59 -0000 Hi, >>>> Section 6.1.4 of jsep-01 says: >>>> >>>> "SDP_PRANSWER indicates that a description should be parse= d as an >>>> answer, but not a final answer, and so should not result = in the >>>> starting of media transmission. A description used as a S= DP_PRANSWER >>>> may be applied as a response to a SDP_OFFER, or an update= to a >>>> previously sent SDP_PRANSWER." >>>> >>>> >>>> Section 7.6 shows a SIP early media (FEDEX) use-case, where an SDP= answer received in a SIP 18x response is provided to the browser as a SDP_= PRANSWER. >>>> >>>> >>>> Q1: Since SDP_PRANSWER is not supposed to start media transmission= , how will the use-case work? As far as I know, media transmission is neede= d for the FEDEX use-case. >>> >>> >>> I think this is just me being unclear. When I say "start media transmis= sion", I mean that when the browser gets a SDP_PRANSWER >>> in response to an offer, the browser will not start transmitting media.= However, it will play out any media that is received >>> after the offer is installed, and the gateway can start sending media a= t any time after it gets the offer. >> >> Again, you could achieve that using SDP_ANSWER and a direction attribute= (a=3Drecvonly). I don't think we need SDP_PRANSWER for unidirectional medi= a purpose. >> >> (And, as was mentioned, there may actually be a need to also transmit me= dia for the FEDEX case) > > I think I tired to cover this in some of my slides before. You end up wit= h this problem if you map the 180 to a final answer, then when the 200 come= s along, it is=20 > less clear what to do with it. If you map it to offer, then it's unclear = how to handle the answer that comes in response to it. You would not map it to an offer - you would replace the previous answer. > I think I had some slides that showed this at one point. Basically, I don= 't see how using using an answer will work. The issue is not if you are sen= ding or=20 > receiving one way media, the issue is when you can free resources allocat= ed in the offer but not needed in the answer. That is a good point. Regards, Christer From juberti@google.com Fri Feb 17 15:00: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 EEC3621F8630 for ; Fri, 17 Feb 2012 15:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.759 X-Spam-Level: X-Spam-Status: No, score=-102.759 tagged_above=-999 required=5 tests=[AWL=0.217, 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 elZ-+lT225fJ for ; Fri, 17 Feb 2012 15:00:01 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 84A9B21F862D for ; Fri, 17 Feb 2012 15:00:01 -0800 (PST) Received: by qafi29 with SMTP id i29so1339018qaf.10 for ; Fri, 17 Feb 2012 15:00:00 -0800 (PST) Received-SPF: pass (google.com: domain of juberti@google.com designates 10.229.77.15 as permitted sender) client-ip=10.229.77.15; Authentication-Results: mr.google.com; spf=pass (google.com: domain of juberti@google.com designates 10.229.77.15 as permitted sender) smtp.mail=juberti@google.com; dkim=pass header.i=juberti@google.com Received: from mr.google.com ([10.229.77.15]) by 10.229.77.15 with SMTP id e15mr7409786qck.66.1329519600787 (num_hops = 1); Fri, 17 Feb 2012 15:00:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=uo1QCT3JTZri+Sq2bs1b28M3g88jpgRYsSJCwxe+UMo=; b=Zz6kn455Sqsd3+boeHex1Sj7JTRw004GkfX7l9RqRvAI+dcaNFi3cEv6ATNcm9VUJq XFbpj9yrX2reDQ+W0X/3rFArMu8N8YksNE10rO78cuC6Da2tnnCh3iPTa798NXRnurNJ cAcOzcF7DWQkTY0fPkItHgbvVEc/CmVkRfJdk= Received: by 10.229.77.15 with SMTP id e15mr6246334qck.66.1329519600604; Fri, 17 Feb 2012 15:00:00 -0800 (PST) Received: by 10.229.77.15 with SMTP id e15mr6246321qck.66.1329519600382; Fri, 17 Feb 2012 15:00:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.29.195 with HTTP; Fri, 17 Feb 2012 14:59:40 -0800 (PST) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3D31BA2B@ESESSCMS0356.eemea.ericsson.se> References: <387F9047F55E8C42850AD6B3A7A03C6C0E03F8A4@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E03FAB5@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E03FB7C@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E03FC20@inba-mail01.sonusnet.com> <9ED4A9AC-37C7-4E6D-B6C6-4D3C9537B356@iii.ca> <387F9047F55E8C42850AD6B3A7A03C6C0E040130@inba-mail01.sonusnet.com> <935E62D2-61EB-4E53-98D7-E2BC78AC0B41@iii.ca> <7F2072F1E0DE894DA4B517B93C6A05852C3D31BA2B@ESESSCMS0356.eemea.ericsson.se> From: Justin Uberti Date: Fri, 17 Feb 2012 17:59:40 -0500 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=00235446fe5880b43204b930e758 X-System-Of-Record: true X-Gm-Message-State: ALoCoQngzLr9WAIiH538FvItX4RHXQCzm6QjjywKJqrWx7yH8CEq/7CXAJ+ItP5Ads8awa/txQABTXozu5jtQm3oGg8u/UmObKRT9o4BkT8SsREEY7kG4JAi51Xar2nq3STebIZ5JdpZ1DQb2M7oCxYr6niz2zJKLg== Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] Single offer with multiple answer handling in JSEP [was RE: New JSEP draft posted] 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, 17 Feb 2012 23:00:04 -0000 --00235446fe5880b43204b930e758 Content-Type: text/plain; charset=UTF-8 On Fri, Feb 17, 2012 at 5:36 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > > Hi, > > I can of course only speak for myself, but in all my years of working with > SIP systems I have never encountered a use case where multiple 200 > responses would have to be accepted. In most cases the first 2xx will be > accepted, and any subsequent 2xx will be ACKed+ BYEed. > > However, from a browser perspective I don't think it matters whether the > answers are received in 18x responses or 2xx responses. The fact is that > multiple answers may be received, and the browser needs to be able to > handle that. > > And, it seems like people agree that a new answer would replace the old > one, as also suggested by Justin below. > To be clear, the JS can either decide that first one wins, or last one wins, or whatever it wants. At setRemoteDescription level though, whatever you supply (if you do it at all) will replace the previous description. > > And, IF someone wants to establish simultanous dialogs with multiple > remote entities, in my opinion it would then be better to e.g. create > multiple PeerConnections (one for each remote entity), or something like > that. > Agree. > > Regards, > > Christer > > ________________________________________ > From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] On Behalf Of > Cullen Jennings [fluffy@iii.ca] > Sent: Friday, February 17, 2012 11:21 PM > To: Justin Uberti > Cc: rtcweb@ietf.org; public-webrtc@w3.org > Subject: Re: [rtcweb] Single offer with multiple answer handling in JSEP > [was RE: New JSEP draft posted] > > I'm most interested in real world use cases which if they were being done > with SIP would result in multiple 200 being processed by the browser. I > have not got my head around why this would be needed yet and without the > use cases I'm having a hard time deciding if there is a problem or not. > > > On Feb 16, 2012, at 7:35 PM, Justin Uberti wrote: > > > Agree it has not been addressed. I'm having some trouble understanding > the exact flows that we need to address here (multiple 2xx, multiple 18x > followed by 2xx, multiple 18x followed by multiple 2xx) but if I understand > correctly your suggestion was: > > > > 1) allow a setRemoteDesc(SDP_ANSWER) to follow a > setRemoteDesc(SDP_ANSWER) > > 2) document that in this case (multiple 2xx), the JS is responsible for > sending BYE to the previous answerer. > > > > which sounds totally reasonable to me. > > > > If this sounds good to you, would you mind sketching out a call flow > that I could include in the examples section? > > > > On Thu, Feb 16, 2012 at 2:11 AM, Ravindran, Parthasarathi < > pravindran@sonusnet.com> wrote: > > Cullen/Justin, > > > > Single offer with multiple answer open item is not addressed in -02 > version of JSEP draft. Hope you first agree this as an open item in JSEP. > > > > Thanks > > Partha > > > > >-----Original Message----- > > >From: Ravindran, Parthasarathi > > >Sent: Wednesday, February 15, 2012 2:43 PM > > >To: 'Cullen Jennings' > > >Cc: Justin Uberti; rtcweb@ietf.org; public-webrtc@w3.org > > >Subject: RE: [rtcweb] Single offer with multiple answer handling in JSEP > > >[was RE: New JSEP draft posted] > > > > > >Cullen, > > > > > >RFC3261 references for receiving multiple 2xx in UAC which does not fork > > >INVITE are as follows: > > > > > > > > >Sec 13.1 Para 3: > > > > > >Therefore, when multiple 2xx responses are received from different > > >remote UAs (because the INVITE forked), each 2xx establishes a different > > >dialog. All these dialogs are part of the same call. > > > > > >Sec 13.2.2.4 2xx Responses > > > > > > Multiple 2xx responses may arrive at the UAC for a single INVITE > > > request due to a forking proxy. Each response is distinguished by > > > the tag parameter in the To header field, and each represents a > > > distinct dialog, with a distinct dialog identifier. > > > > > > If, after acknowledging any 2xx response to an INVITE, the UAC does > > > not want to continue with that dialog, then the UAC MUST terminate > > > the dialog by sending a BYE request as described in Section 15. > > > > > > > > >As per the last statements, it is upto the SIP application to decide > > >which one of the final 2xx response has to be included within the call. > > >The usecase 3 is based on RFC3262 (PRACK) support wherein it is possible > > >to receive multiple forked 18x with SDP followed by 2xx with or without > > >SDP and SIP 2xx response is not tied to offer/answer exchange. > > > > > >I have provided mobile to desktop as an example to justify the last > > >answer may be used in the offer in some JS application. As I mentioned > > >below, there is no need to restrict updating latest answer for an offer > > >in terms of API and protocol. > > > > > >Thanks > > >Partha > > > > > >>-----Original Message----- > > >>From: Cullen Jennings [mailto:fluffy@iii.ca] > > >>Sent: Wednesday, February 15, 2012 1:31 PM > > >>To: Ravindran, Parthasarathi > > >>Cc: Justin Uberti; rtcweb@ietf.org; public-webrtc@w3.org > > >>Subject: Re: [rtcweb] Single offer with multiple answer handling in > > >>JSEP [was RE: New JSEP draft posted] > > >> > > >> > > >>I'm a bit lost on use case in SIP context - assuming that the UAC did > > >>not fork but that a proxy or B2BUA did the forking, it seems like the > > >>UAC should never receive more than one final response. > > >> > > >>In the case of moving from desktop to mobile, it seems like that is > > >>updating the stream and would use a call flow more like update examples > > >>in the draft instead of trying to reuse some old answer. > > >> > > >> > > >>On Feb 14, 2012, at 11:24 , Ravindran, Parthasarathi wrote: > > >> > > >>> Justin, > > >>> > > >>> Some of the usecases could be > > >>> 1) The same user of a website signed-in in the multiples devices > > >>and acts as answerer, the session establishment request to the > > >>identity will alert all the signed-in devices and it is possible that > > >>multiple devices answer to the session. Here, user may move from one > > >>device > > >>(mobile) to another device (desktop) within the session and wishes to > > >>continue the session with the last answer. Please note that website is > > >>flexible to provide this service. > > >>> 2) RFC 3261 SIP UA offer/answer handling w.r.t INVITE with SDP > > >to > > >>multiple 2xx with SDP handling scenario using JSEP > > >>> 3) Another SIP usecase could be multiple 18x responses with SDP > > >>for INVITE with SDP and multiple 2xx responses without SDP but order > > >>within 18x and 200 are not same. Say 2xx of the second 18x is received > > >>as the first 2xx. Here, we need to know how second 18x is handled and > > >>also, the subsequent 2xx is handled. > > >>> > > >>> Of course, it is possible to build more usecases around this area. As > > >>we made signaling outside the scope of WebRTC, it is upto JS > > >>application to decide the order in which offer/answer happens. I'm not > > >>relating offer/answer FSM with session establishment state like 18x, > > >>2xx but I'm interested in knowing browser media plane behavior in > > >>different state of offer/answer handling by which JS application > > >>behaves consistently in all browsers. > > >>> > > >>> Thanks > > >>> Partha > > >>> > > >>> > > >>> From: Justin Uberti [mailto:juberti@google.com] > > >>> Sent: Tuesday, February 14, 2012 11:36 PM > > >>> To: Ravindran, Parthasarathi > > >>> Cc: rtcweb@ietf.org; public-webrtc@w3.org > > >>> Subject: Re: Single offer with multiple answer handling in JSEP [was > > >>RE: [rtcweb] New JSEP draft posted] > > >>> > > >>> Partha, > > >>> > > >>> I need more information about the use case to provide an accurate > > >>response. As mentioned in my earlier mail, are both answers 2xx > > >>responses? > > >>> > > >>> On Tue, Feb 14, 2012 at 12:17 PM, Ravindran, Parthasarathi > > >> wrote: > > >>> Hi Justin, > > >>> > > >>> In this mail thread, Let us define the behavior of multiple (atleast > > >>two) answers for the single offer in WebRTC browser. Now, Please let > > >>me know your opinion for my below mail. > > >>> > > >>> Thanks > > >>> Partha > > >>> > > >>> From: Justin Uberti [mailto:juberti@google.com] > > >>> Sent: Tuesday, February 14, 2012 9:47 PM > > >>> > > >>> To: Ravindran, Parthasarathi > > >>> Cc: rtcweb@ietf.org; public-webrtc@w3.org > > >>> Subject: Re: Single offer with multiple answer handling in JSEP [was > > >>RE: [rtcweb] New JSEP draft posted] > > >>> > > >>> > > >>> > > >>> On Tue, Feb 14, 2012 at 6:39 AM, Ravindran, Parthasarathi > > >> wrote: > > >>> Hi Justin, > > >>> > > >>> It will be good to mention in the JSEP draft that multiple answers > > >>for single offer will not lead to RTP Mixing and WebRTC client acts as > > >>RTP Endpoint. > > >>> > > >>> Failing the second Answer will be limiting the provision in RFC 3264 > > >>offer/answer itself as RFC 3264 supports single offer with multiple > > >>answer. Also, it is better to define the behavior in API rather than > > >>putting this scenario in the browser implementation specific. In simple > > >>scenarios (like alerting with one answer, connect with second answer), > > >>replacing the previous ANSWER will be expected behavior. This may not > > >>be desired behavior in case two connect responses from different WebRTC > > >>clients received with different answers but there is no other > > >>alternative solution possible without mixing. > > >>> > > >>> Do you need to support 2 final answers, or would the provisional > > >>answer support provided via SDP_PRANSWER work for you? > > >>> > > >>> IMO, it is better to define it explicitly in JSEP that "latest ANSWER > > >>to the offer will replace the existing answer is the expected behavior > > >>". Also, Please mentioned that JS application is responsible for > > >>discarding (terminating) previous ANSWER notification. Please let me > > >>your opinion on this closure. > > >>> > > >>> Thanks > > >>> Partha > > >>> > > >>> From: Justin Uberti [mailto:juberti@google.com] > > >>> Sent: Tuesday, February 14, 2012 7:29 PM > > >>> To: Ravindran, Parthasarathi > > >>> Cc: rtcweb@ietf.org; public-webrtc@w3.org > > >>> Subject: Re: Single offer with multiple answer handling in JSEP [was > > >>RE: [rtcweb] New JSEP draft posted] > > >>> > > >>> Regarding your previous mail, an ANSWER after an ANSWER would either > > >>fail (if we wanted to simplify), or replace the previous ANSWER > > >>(essentially the same as if you had done setLocalDescription(OFFER, > > >>localDescription) followed by setRemoteDescription(ANSWER, answer2). > > >>> > > >>> In no case would it mix the descriptions/media from both answers. > > >>> > > >>> Other comments inline below. > > >>> > > >>> On Tue, Feb 14, 2012 at 1:24 AM, Ravindran, Parthasarathi > > >> wrote: > > >>> Hi Justin, > > >>> > > >>> Adding to my earlier mail, In case answer2 SDP is updated in offerer1 > > >>browser without notifying answerer1, then answer1 will continue to > > >>transmit RTP which may not be desired behavior. IMO, we need to define > > >>this behavior clearly in offerer side. Some of the possible solutions > > >>are > > >>> > > >>> 1) offerer1 has to send atleast RTCP BYE packets towards > > >>answerer1 while accepting the answerer2 SDP. > > >>> > > >>> 2) Throw callback to clear answer1 SDP towards offererJS. > > >>> > > >>> > > >>> The application which called setRemoteDescription twice should have > > >>the best idea about what is going on, and therefore is responsible for > > >>notifying answerer1 that its answer has been discarded, if it makes > > >>sense to do so. No callback should be needed here. > > >>> > > >>> > > >>> Please let me know your opinion here. > > >>> > > >>> Thanks > > >>> Partha > > >>> > > >>> From: Ravindran, Parthasarathi > > >>> Sent: Tuesday, February 14, 2012 12:07 AM > > >>> To: 'Justin Uberti'; rtcweb@ietf.org; public-webrtc@w3.org > > >>> Subject: Single offer with multiple answer handling in JSEP [was RE: > > >>[rtcweb] New JSEP draft posted] > > >>> > > >>> Hi Justin, > > >>> > > >>> In the draft, it is not spelled out explicitly what is the expected > > >>behavior in offerer browser in case multiple answer is received for > > >>single offer. Offer/answer exchange in offerer is as follows: > > >>> > > >>> OffererJS->OffererUA: var offer = pc.createOffer(null); > > >>> OffererJS->OffererUA: pc.setLocalDescription(SDP_OFFER, offer); > > >>> OffererJS->OffererUA: pc.setRemoteDescription(SDP_ANSWER, answer1); > > >>> OffererUA->Answerer1UA: > > >>> OffererJS->OffererUA: pc.setRemoteDescription(SDP_ANSWER, answer2); > > >>> OffererUA->Answerer?UA: ? > > >>> > > >>> My understanding is that "answer2" will update "answer1" in browser > > >>and starting sending/receiving media towards answer2 media IP and port. > > >>Could you please explain the expected behavior in offerer browser > > >>whether it updates the media stream based on the last answer or mixes > > >>both answerer. > > >>> > > >>> Thanks > > >>> Partha > > >>> > > >>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > > >>Behalf Of Justin Uberti > > >>> Sent: Thursday, February 09, 2012 2:27 AM > > >>> To: rtcweb@ietf.org; public-webrtc@w3.org > > >>> Subject: [rtcweb] New JSEP draft posted > > >>> > > >>> Now available at http://www.ietf.org/id/draft-uberti-rtcweb-jsep- > > >>01.txt > > >>> > > >>> Includes changes based on implementation feedback, and I believe it > > >>addresses most of the concerns raised in last week's interim meetings: > > >>> - Initial documentation provided for each API call, and what state > > >>changes it causes > > >>> - More examples, including a complete basic sample application > > >>> - Simplified approach to trickle candidate handling > > >>> - Resolved concerns about how to separate SDP attributes into media / > > >>transport > > >>> - Provided encapsulation for SDP blobs and ICE candidate lines, in > > >>> the > > >>event we want to change encodings or provide helper functions for JS > > >>> - Provided mechanism for limiting candidates to TURN-only > > >>> - Resolved several implementation issues > > >>> > > >>> I have not yet addressed the non-overlapping codec concern mentioned > > >>in the interim meeting. I think there are ways of handling this either > > >>in the application or the implementation, but I wanted to get this -01 > > >>out first for feedback. > > >>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> 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 > --00235446fe5880b43204b930e758 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Feb 17, 2012 at 5:36 PM, Christe= r Holmberg <christer.holmberg@ericsson.com> wrote:

Hi,

I can of course only speak for myself, but in all my years of working with = SIP systems I have never encountered a use case where multiple 200 response= s would have to be accepted. In most cases the first 2xx will be accepted, = and any subsequent 2xx will be ACKed+ BYEed.

However, from a browser perspective I don't think it matters whether th= e answers are received in 18x responses or 2xx responses. The fact is that = multiple answers may be received, and the browser needs to be able to handl= e that.

And, it seems like people agree that a new answer would replace the old one= , as also suggested by Justin below.

To= be clear, the JS can either decide that first one wins, or last one wins, = or whatever it wants. At setRemoteDescription level though, whatever you su= pply (if you do it at all) will replace the previous description.=C2=A0

And, IF someone wants to establish simultanous dialogs with multiple remote= entities, in my opinion it would then be better to e.g. create multiple Pe= erConnections (one for each remote entity), or something like that.

Agree.
=C2=A0

Regards,

Christer

________________________________________
From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] = On Behalf Of Cullen Jennings [fluffy@iii.c= a]
Sent: Friday, February 17, 2012 11:21 PM
To: Justin Uberti
Cc: rtcweb@ietf.org; public-webrtc@w3.org
Subject: Re: [rtcweb] Single offer = with multiple answer handling in JSEP =C2=A0 =C2=A0 =C2=A0 =C2=A0[was RE: N= ew JSEP draft posted]

I'm most interested in real world use cases which if they were being do= ne with SIP would result in multiple 200 being processed by the browser. I = have not got my head around why this would be needed yet and without the us= e cases I'm having a hard time deciding if there is a problem or not.

On Feb 16, 2012, at 7:35 PM, Justin Uberti wrote:

> Agree it has not been addressed. I'm having some trouble understan= ding the exact flows that we need to address here (multiple 2xx, multiple 1= 8x followed by 2xx, multiple 18x followed by multiple 2xx) but if I underst= and correctly your suggestion was:
>
> 1) allow a setRemoteDesc(SDP_ANSWER) to follow a setRemoteDesc(SDP_ANS= WER)
> 2) document that in this case (multiple 2xx), the JS is responsible fo= r sending BYE to the previous answerer.
>
> which sounds totally reasonable to me.
>
> If this sounds good to you, would you mind sketching out a call flow t= hat I could include in the examples section?
>
> On Thu, Feb 16, 2012 at 2:11 AM, Ravindran, Parthasarathi <pravindran@sonusnet.com> wrote:<= br> > Cullen/Justin,
>
> Single offer with multiple answer open item is not addressed in -02 ve= rsion of JSEP draft. Hope you first agree this as an open item in JSEP.
>
> Thanks
> Partha
>
> >-----Original Message-----
> >From: Ravindran, Parthasarathi
> >Sent: Wednesday, February 15, 2012 2:43 PM
> >To: 'Cullen Jennings'
> >Cc: Justin Uberti; rtcweb@ietf.= org; public-webrtc@w3.org > >Subject: RE: [rtcweb] Single offer with multiple answer handling i= n JSEP
> >[was RE: New JSEP draft posted]
> >
> >Cullen,
> >
> >RFC3261 references for receiving multiple 2xx in UAC which does no= t fork
> >INVITE are as follows:
> >
> ><RFC quote>
> >Sec 13.1 Para 3:
> >
> >Therefore, when multiple 2xx responses are received from different=
> >remote UAs (because the INVITE forked), each 2xx establishes a dif= ferent
> >dialog. =C2=A0All these dialogs are part of the same call.
> >
> >Sec 13.2.2.4 2xx Responses
> >
> > =C2=A0 Multiple 2xx responses may arrive at the UAC for a single = INVITE
> > =C2=A0 request due to a forking proxy. =C2=A0Each response is dis= tinguished by
> > =C2=A0 the tag parameter in the To header field, and each represe= nts a
> > =C2=A0 distinct dialog, with a distinct dialog identifier.
> >
> > =C2=A0 If, after acknowledging any 2xx response to an INVITE, the= UAC does
> > =C2=A0 not want to continue with that dialog, then the UAC MUST t= erminate
> > =C2=A0 the dialog by sending a BYE request as described in Sectio= n 15.
> ></RFC quote>
> >
> >As per the last statements, it is upto the SIP application to deci= de
> >which one of the final 2xx response has to be included within the = call.
> >The usecase 3 is based on RFC3262 (PRACK) support wherein it is po= ssible
> >to receive multiple forked 18x with SDP followed by 2xx with or wi= thout
> >SDP and SIP 2xx response is not tied to offer/answer exchange.
> >
> >I have provided mobile to desktop as an example to justify the las= t
> >answer may be used in the offer in some JS application. As I menti= oned
> >below, there is no need to restrict updating latest answer for an = offer
> >in terms of API and protocol.
> >
> >Thanks
> >Partha
> >
> >>-----Original Message-----
> >>From: Cullen Jennings [mailto:fluffy@iii.ca]
> >>Sent: Wednesday, February 15, 2012 1:31 PM
> >>To: Ravindran, Parthasarathi
> >>Cc: Justin Uberti; rtcweb@i= etf.org; public-webrtc@w3.org
> >>Subject: Re: [rtcweb] Single offer with multiple answer handli= ng in
> >>JSEP [was RE: New JSEP draft posted]
> >>
> >>
> >>I'm a bit lost on use case in SIP context - assuming that = the UAC did
> >>not fork but that a proxy or B2BUA did the forking, it seems l= ike the
> >>UAC should never receive more than one final response.
> >>
> >>In the case of moving from desktop to mobile, it seems like th= at is
> >>updating the stream and would use a call flow more like update= examples
> >>in the draft instead of trying to reuse some old answer.
> >>
> >>
> >>On Feb 14, 2012, at 11:24 , Ravindran, Parthasarathi wrote: > >>
> >>> Justin,
> >>>
> >>> Some of the usecases could be
> >>> 1) =C2=A0 =C2=A0 =C2=A0The same user of a website signed-= in in the multiples devices
> >>and acts as answerer, =C2=A0the session establishment request = to the
> >>identity will alert all the signed-in devices and it is possib= le that
> >>multiple devices answer to the session. Here, user may move fr= om one
> >>device
> >>(mobile) to another device (desktop) within the session and wi= shes to
> >>continue the session with the last answer. Please note that we= bsite is
> >>flexible to provide this service.
> >>> 2) =C2=A0 =C2=A0 =C2=A0RFC 3261 SIP UA offer/answer handl= ing w.r.t INVITE with SDP
> >to
> >>multiple 2xx with SDP handling scenario using JSEP
> >>> 3) =C2=A0 =C2=A0 =C2=A0Another SIP usecase could be multi= ple 18x responses with SDP
> >>for INVITE with SDP and multiple 2xx responses without SDP but= order
> >>within 18x and 200 are not same. Say 2xx of the second 18x is = received
> >>as the first 2xx. Here, we need to know how second 18x is hand= led and
> >>also, the subsequent 2xx is handled.
> >>>
> >>> Of course, it is possible to build more usecases around t= his area. As
> >>we made signaling outside the scope of WebRTC, it is upto JS > >>application to decide the order in which offer/answer happens.= I'm not
> >>relating offer/answer FSM with session establishment state lik= e 18x,
> >>2xx but I'm interested in knowing browser media plane beha= vior in
> >>different state of offer/answer handling by which JS applicati= on
> >>behaves consistently in all browsers.
> >>>
> >>> Thanks
> >>> Partha
> >>>
> >>>
> >>> From: Justin Uberti [mailto:juberti@google.com]
> >>> Sent: Tuesday, February 14, 2012 11:36 PM
> >>> To: Ravindran, Parthasarathi
> >>> Cc: rtcweb@ietf.org; public-webrtc@w3.org
> >>> Subject: Re: Single offer with multiple answer handling i= n JSEP [was
> >>RE: [rtcweb] New JSEP draft posted]
> >>>
> >>> Partha,
> >>>
> >>> I need more information about the use case to provide an = accurate
> >>response. As mentioned in my earlier mail, are both answers 2x= x
> >>responses?
> >>>
> >>> On Tue, Feb 14, 2012 at 12:17 PM, Ravindran, Parthasarath= i
> >><pravindran@sonu= snet.com> wrote:
> >>> Hi Justin,
> >>>
> >>> In this mail thread, Let us define the behavior of multip= le (atleast
> >>two) answers for the single offer in WebRTC browser. =C2=A0Now= , Please let
> >>me know your opinion for my below mail.
> >>>
> >>> Thanks
> >>> Partha
> >>>
> >>> From: Justin Uberti [mailto:juberti@google.com]
> >>> Sent: Tuesday, February 14, 2012 9:47 PM
> >>>
> >>> To: Ravindran, Parthasarathi
> >>> Cc: rtcweb@ietf.org; public-webrtc@w3.org
> >>> Subject: Re: Single offer with multiple answer handling i= n JSEP [was
> >>RE: [rtcweb] New JSEP draft posted]
> >>>
> >>>
> >>>
> >>> On Tue, Feb 14, 2012 at 6:39 AM, Ravindran, Parthasarathi=
> >><pravindran@sonu= snet.com> wrote:
> >>> Hi Justin,
> >>>
> >>> It will be good to mention in the JSEP draft =C2=A0that m= ultiple answers
> >>for single offer will not lead to RTP Mixing and WebRTC client= acts as
> >>RTP Endpoint.
> >>>
> >>> Failing the second Answer will be limiting the provision = in RFC 3264
> >>offer/answer itself as RFC 3264 supports single offer with mul= tiple
> >>answer. Also, it is better to define the behavior in API rathe= r than
> >>putting this scenario in the browser implementation specific. = In simple
> >>scenarios (like alerting with one answer, connect with second = answer),
> >>replacing the previous ANSWER will be expected behavior. This = may not
> >>be desired behavior in case two connect responses from differe= nt WebRTC
> >>clients received with different answers =C2=A0but there is no = other
> >>alternative solution possible without mixing.
> >>>
> >>> Do you need to support 2 final answers, or would the prov= isional
> >>answer support provided via SDP_PRANSWER work for you?
> >>>
> >>> IMO, it is better to define it explicitly in JSEP that &q= uot;latest ANSWER
> >>to the offer will replace the existing answer is the expected = behavior
> >>". Also, Please mentioned that JS application is responsi= ble for
> >>discarding (terminating) previous ANSWER notification. =C2=A0 = Please let me
> >>your opinion on this closure.
> >>>
> >>> Thanks
> >>> Partha
> >>>
> >>> From: Justin Uberti [mailto:juberti@google.com]
> >>> Sent: Tuesday, February 14, 2012 7:29 PM
> >>> To: Ravindran, Parthasarathi
> >>> Cc: rtcweb@ietf.org; public-webrtc@w3.org
> >>> Subject: Re: Single offer with multiple answer handling i= n JSEP [was
> >>RE: [rtcweb] New JSEP draft posted]
> >>>
> >>> Regarding your previous mail, an ANSWER after an ANSWER w= ould either
> >>fail (if we wanted to simplify), or replace the previous ANSWE= R
> >>(essentially the same as if you had done setLocalDescription(O= FFER,
> >>localDescription) followed by setRemoteDescription(ANSWER, ans= wer2).
> >>>
> >>> In no case would it mix the descriptions/media from both = answers.
> >>>
> >>> Other comments inline below.
> >>>
> >>> On Tue, Feb 14, 2012 at 1:24 AM, Ravindran, Parthasarathi=
> >><pravindran@sonu= snet.com> wrote:
> >>> Hi Justin,
> >>>
> >>> Adding to my earlier mail, In case answer2 SDP is updated= in offerer1
> >>browser without notifying answerer1, then answer1 will continu= e to
> >>transmit RTP which may not be desired behavior. IMO, we need t= o define
> >>this behavior clearly in offerer side. Some of the possible so= lutions
> >>are
> >>>
> >>> 1) =C2=A0 =C2=A0 =C2=A0offerer1 has to send atleast RTCP = BYE packets towards
> >>answerer1 while accepting the answerer2 SDP.
> >>>
> >>> 2) =C2=A0 =C2=A0 =C2=A0Throw callback to clear answer1 SD= P towards offererJS.
> >>>
> >>>
> >>> The application which called setRemoteDescription twice s= hould have
> >>the best idea about what is going on, and therefore is respons= ible for
> >>notifying answerer1 that its answer has been discarded, if it = makes
> >>sense to do so. No callback should be needed here.
> >>>
> >>>
> >>> Please let me know your opinion here.
> >>>
> >>> Thanks
> >>> Partha
> >>>
> >>> From: Ravindran, Parthasarathi
> >>> Sent: Tuesday, February 14, 2012 12:07 AM
> >>> To: 'Justin Uberti'; rtcweb@ietf.org; public-= webrtc@w3.org
> >>> Subject: Single offer with multiple answer handling in JS= EP [was RE:
> >>[rtcweb] New JSEP draft posted]
> >>>
> >>> Hi Justin,
> >>>
> >>> In the draft, it is not spelled out explicitly what is th= e expected
> >>behavior in offerer browser in case multiple answer is receive= d for
> >>single offer. Offer/answer exchange in offerer is as follows:<= br> > >>>
> >>> OffererJS->OffererUA: var offer =3D pc.createOffer(nul= l);
> >>> OffererJS->OffererUA: pc.setLocalDescription(SDP_OFFER= , offer);
> >>> OffererJS->OffererUA: =C2=A0pc.setRemoteDescription(SD= P_ANSWER, answer1);
> >>> OffererUA->Answerer1UA: <media>
> >>> OffererJS->OffererUA: =C2=A0pc.setRemoteDescription(SD= P_ANSWER, answer2);
> >>> OffererUA->Answerer?UA: <media>?
> >>>
> >>> My understanding is that "answer2" will update = "answer1" in browser
> >>and starting sending/receiving media towards answer2 media IP = and port.
> >>Could you please explain the expected behavior in offerer brow= ser
> >>whether it updates the media stream based on the last answer o= r mixes
> >>both answerer.
> >>>
> >>> Thanks
> >>> Partha
> >>>
> >>> From: rtcweb-b= ounces@ietf.org [mailto:rtcw= eb-bounces@ietf.org] On
> >>Behalf Of Justin Uberti
> >>> Sent: Thursday, February 09, 2012 2:27 AM
> >>> To: rtcweb@ietf.org; public-webrtc@w3.org
> >>> Subject: [rtcweb] New JSEP draft posted
> >>>
> >>> Now available at http://www.ietf.org/id/draft-uberti-= rtcweb-jsep-
> >>01.txt
> >>>
> >>> Includes changes based on implementation feedback, and I = believe it
> >>addresses most of the concerns raised in last week's inter= im meetings:
> >>> - Initial documentation provided for each API call, and w= hat state
> >>changes it causes
> >>> - More examples, including a complete basic sample applic= ation
> >>> - Simplified approach to trickle candidate handling
> >>> - Resolved concerns about how to separate SDP attributes = into media /
> >>transport
> >>> - Provided encapsulation for SDP blobs and ICE candidate = lines, in
> >>> the
> >>event we want to change encodings or provide helper functions = for JS
> >>> - Provided mechanism for limiting candidates to TURN-only=
> >>> - Resolved several implementation issues
> >>>
> >>> I have not yet addressed the non-overlapping codec concer= n mentioned
> >>in the interim meeting. I think there are ways of handling thi= s either
> >>in the application or the implementation, but I wanted to get = this -01
> >>out first for feedback.
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> 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

--00235446fe5880b43204b930e758-- From bernard_aboba@hotmail.com Fri Feb 17 17:46: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 AA6BB21F8540 for ; Fri, 17 Feb 2012 17:46:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.275 X-Spam-Level: X-Spam-Status: No, score=-101.275 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_05=-1.11, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eamIU5IqYA52 for ; Fri, 17 Feb 2012 17:46:09 -0800 (PST) Received: from blu0-omc3-s26.blu0.hotmail.com (blu0-omc3-s26.blu0.hotmail.com [65.55.116.101]) by ietfa.amsl.com (Postfix) with ESMTP id 189D921F853C for ; Fri, 17 Feb 2012 17:46:09 -0800 (PST) Received: from BLU152-W1 ([65.55.116.74]) by blu0-omc3-s26.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 17 Feb 2012 17:46:08 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_63023ef9-be6b-433f-9540-f36eb6c95d5b_" X-Originating-IP: [131.107.0.87] From: Bernard Aboba To: Date: Fri, 17 Feb 2012 17:46:08 -0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 18 Feb 2012 01:46:08.0519 (UTC) FILETIME=[15BE6170:01CCEDDF] Subject: [rtcweb] Section 5.2.1 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, 18 Feb 2012 01:46:09 -0000 --_63023ef9-be6b-433f-9540-f36eb6c95d5b_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Section 5.2.1 in the JSEP-02 draft raised a question: "This step will also cause encoder resources to be allocated=2C based on th= e codecs specified in |offer|." [BA] Should the answerer allocate encoding resources based on the codecs sp= ecified in the answer=2C as opposed to the offer?=20 setRemoteDescription(SDP_OFFER=2C offer) sets the SRTP keys used to receive= =2C then setLocalDescription(SDP_ANSWER=2C answer) causes transmission of media by the answerer.=20 = --_63023ef9-be6b-433f-9540-f36eb6c95d5b_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Section 5.2.1 in the JSEP-02 draft raised a question:

"This step wil= l also cause encoder resources to be allocated=2C based on the codecs speci= fied in |offer|."

[BA] Should the answerer allocate encoding resourc= es based on the codecs specified in the answer=2C as opposed to the offer? =

setRemoteDescription(SDP_OFFER=2C offer) sets the SRTP keys used to= receive=2C then setLocalDescription(SDP_ANSWER=2C answer)
causes transm= ission of media by the answerer.
= --_63023ef9-be6b-433f-9540-f36eb6c95d5b_-- From bernard_aboba@hotmail.com Fri Feb 17 19:45: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 4D2A721E8013 for ; Fri, 17 Feb 2012 19:45:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAhQVC1FN5hH for ; Fri, 17 Feb 2012 19:45:50 -0800 (PST) Received: from dub0-omc1-s2.dub0.hotmail.com (dub0-omc1-s2.dub0.hotmail.com [157.55.0.201]) by ietfa.amsl.com (Postfix) with ESMTP id 884DA21E8022 for ; Fri, 17 Feb 2012 19:45:50 -0800 (PST) Received: from DUB0-P4-EAS17 ([157.55.0.237]) by dub0-omc1-s2.dub0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 17 Feb 2012 19:45:49 -0800 X-Originating-IP: [98.96.53.134] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: References: From: Bernard Aboba Content-Type: multipart/alternative; boundary="Apple-Mail-35F1F3F4-D50B-4BE2-9FEB-A058393E17C0" In-Reply-To: Date: Fri, 17 Feb 2012 19:48:09 -0800 To: rtcweb@ietf.org Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (1.0) X-OriginalArrivalTime: 18 Feb 2012 03:45:49.0470 (UTC) FILETIME=[CDEC8BE0:01CCEDEF] Subject: Re: [rtcweb] Section 5.2.1 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, 18 Feb 2012 03:45:51 -0000 --Apple-Mail-35F1F3F4-D50B-4BE2-9FEB-A058393E17C0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" Other (related) questions Section 6.1.3: "Session descriptions generated by createAnswer must be immediately usable b= y setRemoteDescription; " setRemoteDescription(SDP_ANSWER, answer) called by the offerer (Section 5.3.= 1), but on the Answerer, it is setLocalDescription(SDP_ANSWER, answer) (Sect= ion 5.2.5). Which side is the above sentence referring to? Section 6.1.6: "Changes to the state of media transmission will only occur when a final ans= wer is successfully applied.". =20 Setting PRANSWER aside, is this statement only valid for the offerer? Or doe= s it imply that setRemoteDescription is to be called with an SDP_ANSWER on t= he Answerer? Some nits: Page 6: s/it provides/provides/ Page 16: duplicate 3rd paragraph Page 17: duplicate 3rd paragraph On Feb 17, 2012, at 17:46, "Bernard Aboba" wrote= : > Section 5.2.1 in the JSEP-02 draft raised a question: >=20 > "This step will also cause encoder resources to be allocated, based on the= codecs specified in |offer|." >=20 > [BA] Should the answerer allocate encoding resources based on the codecs s= pecified in the answer, as opposed to the offer?=20 >=20 > setRemoteDescription(SDP_OFFER, offer) sets the SRTP keys used to receive,= then setLocalDescription(SDP_ANSWER, answer) > causes transmission of media by the answerer.=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail-35F1F3F4-D50B-4BE2-9FEB-A058393E17C0 Content-Transfer-Encoding: base64 Content-Type: text/html; charset="utf-8" PGh0bWw+PGhlYWQ+PC9oZWFkPjxib2R5IGJnY29sb3I9IiNGRkZGRkYiPjxkaXY+T3RoZXIgKHJl bGF0ZWQpIHF1ZXN0aW9uczwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+U2VjdGlvbiA2LjEuMzo8 L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PiJTZXNzaW9uIGRlc2NyaXB0aW9ucyBnZW5lcmF0ZWQg YnkgY3JlYXRlQW5zd2VyIG11c3QgYmUgaW1tZWRpYXRlbHkgdXNhYmxlIGJ5IHNldFJlbW90ZURl c2NyaXB0aW9uOyAiPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5zZXRSZW1vdGVEZXNjcmlwdGlv bihTRFBfQU5TV0VSLCBhbnN3ZXIpIGNhbGxlZCBieSB0aGUgb2ZmZXJlciAoU2VjdGlvbiA1LjMu MSksIGJ1dCBvbiB0aGUgQW5zd2VyZXIsIGl0IGlzIHNldExvY2FsRGVzY3JpcHRpb24oU0RQX0FO U1dFUiwgYW5zd2VyKSAoU2VjdGlvbiA1LjIuNSkuICZuYnNwO1doaWNoIHNpZGUgaXMgdGhlIGFi b3ZlIHNlbnRlbmNlIHJlZmVycmluZyB0bz88L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlNlY3Rp b24gNi4xLjY6PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj4iQ2hhbmdlcyB0byB0aGUgc3RhdGUg b2YgbWVkaWEgdHJhbnNtaXNzaW9uIHdpbGwgb25seSBvY2N1ciB3aGVuIGEgZmluYWwgYW5zd2Vy IGlzIHN1Y2Nlc3NmdWxseSBhcHBsaWVkLiIuICZuYnNwOzwvZGl2PjxkaXY+PGJyPjwvZGl2Pjxk aXY+U2V0dGluZyBQUkFOU1dFUiBhc2lkZSwgaXMgdGhpcyBzdGF0ZW1lbnQgb25seSB2YWxpZCBm b3IgdGhlIG9mZmVyZXI/IE9yIGRvZXMgaXQgaW1wbHkgdGhhdCBzZXRSZW1vdGVEZXNjcmlwdGlv biBpcyB0byBiZSBjYWxsZWQgd2l0aCBhbiBTRFBfQU5TV0VSIG9uIHRoZSBBbnN3ZXJlcj88L2Rp dj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlNvbWUgbml0czo8L2Rpdj48ZGl2 Pjxicj48L2Rpdj48ZGl2PlBhZ2UgNjogcy9pdCBwcm92aWRlcy9wcm92aWRlcy88L2Rpdj48ZGl2 PlBhZ2UgMTY6IGR1cGxpY2F0ZSAzcmQgcGFyYWdyYXBoPC9kaXY+PGRpdj5QYWdlIDE3OiBkdXBs aWNhdGUgM3JkIHBhcmFncmFwaDxicj48YnI+PGJyPjwvZGl2PjxkaXY+PGJyPk9uIEZlYiAxNywg MjAxMiwgYXQgMTc6NDYsICJCZXJuYXJkIEFib2JhIiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJlcm5h cmRfYWJvYmFAaG90bWFpbC5jb20iPmJlcm5hcmRfYWJvYmFAaG90bWFpbC5jb208L2E+Jmd0OyB3 cm90ZTo8YnI+PGJyPjwvZGl2PjxkaXY+PC9kaXY+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGRp dj4NCg0KPHN0eWxlPjwhLS0NCi5obW1lc3NhZ2UgUA0Kew0KbWFyZ2luOjBweDsNCnBhZGRpbmc6 MHB4DQp9DQpib2R5LmhtbWVzc2FnZQ0Kew0KZm9udC1zaXplOiAxMHB0Ow0KZm9udC1mYW1pbHk6 VGFob21hDQp9DQotLT48L3N0eWxlPg0KPGRpdiBkaXI9Imx0ciI+DQpTZWN0aW9uIDUuMi4xIGlu IHRoZSBKU0VQLTAyIGRyYWZ0IHJhaXNlZCBhIHF1ZXN0aW9uOjxicj48YnI+IlRoaXMgc3RlcCB3 aWxsIGFsc28gY2F1c2UgZW5jb2RlciByZXNvdXJjZXMgdG8gYmUgYWxsb2NhdGVkLCBiYXNlZCBv biB0aGUgY29kZWNzIHNwZWNpZmllZCBpbiB8b2ZmZXJ8LiI8YnI+PGJyPltCQV0gU2hvdWxkIHRo ZSBhbnN3ZXJlciBhbGxvY2F0ZSBlbmNvZGluZyByZXNvdXJjZXMgYmFzZWQgb24gdGhlIGNvZGVj cyBzcGVjaWZpZWQgaW4gdGhlIGFuc3dlciwgYXMgb3Bwb3NlZCB0byB0aGUgb2ZmZXI/IDxicj48 YnI+c2V0UmVtb3RlRGVzY3JpcHRpb24oU0RQX09GRkVSLCBvZmZlcikgc2V0cyB0aGUgU1JUUCBr ZXlzIHVzZWQgdG8gcmVjZWl2ZSwgdGhlbiBzZXRMb2NhbERlc2NyaXB0aW9uKFNEUF9BTlNXRVIs IGFuc3dlcik8YnI+Y2F1c2VzIHRyYW5zbWlzc2lvbiBvZiBtZWRpYSBieSB0aGUgYW5zd2VyZXIu IDxicj4gCQkgCSAgIAkJICA8L2Rpdj4NCjwvZGl2PjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0 eXBlPSJjaXRlIj48ZGl2PjxzcGFuPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPC9zcGFuPjxicj48c3Bhbj5ydGN3ZWIgbWFpbGluZyBsaXN0PC9zcGFuPjxi cj48c3Bhbj48YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIj5ydGN3ZWJAaWV0Zi5vcmc8 L2E+PC9zcGFuPjxicj48c3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3J0Y3dlYiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9y dGN3ZWI8L2E+PC9zcGFuPjxicj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9ib2R5PjwvaHRtbD4= --Apple-Mail-35F1F3F4-D50B-4BE2-9FEB-A058393E17C0-- From snandaku@cisco.com Fri Feb 17 22:47:40 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 DE11B21F86B0 for ; Fri, 17 Feb 2012 22:47:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.42 X-Spam-Level: X-Spam-Status: No, score=-8.42 tagged_above=-999 required=5 tests=[AWL=-2.179, BAYES_00=-2.599, FRT_VALIUM2=2.643, FUZZY_VLIUM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315, WEIRD_PORT=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 N16AmIeg9B5I for ; Fri, 17 Feb 2012 22:47:38 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 16F8B21F86AD for ; Fri, 17 Feb 2012 22:47:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=snandaku@cisco.com; l=10245; q=dns/txt; s=iport; t=1329547658; x=1330757258; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=NAwQDz90diPbsZsTSuz9Quj2kc4W8BCK9wfrAasqNaQ=; b=HRyNYIiQ8mL9g3ZbUAPMy4rEkEmSolDMeRnfdEHFpyuRyS4vPOUYeCRR Qb6/TnxDIHX/2RsNoaeH8HIdXyf9Jx/Pylx/97AGouDRvZr/1DhddWwEn PGBE7X0Dsg45yNlEmbH5yYFVaAsktegtCKM90h11nB0vrnbKNZZVORi0k Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AioFAAVJP0+tJV2Z/2dsb2JhbABDglGlagGJAGqBB4F3AQQSASo8EgERJ20BAQQBDSeHZ58iAZZli3UDAQEICg8DAQEBAjsDAQaDPDQKJoMcBIgbM4Uch02TCg X-IronPort-AV: E=Sophos;i="4.73,442,1325462400"; d="scan'208,217";a="59961557" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 18 Feb 2012 06:47:36 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q1I6lZHT006288; Sat, 18 Feb 2012 06:47:35 GMT Received: from xmb-rcd-212.cisco.com ([72.163.62.219]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 18 Feb 2012 00:47:35 -0600 Received: from 10.21.114.124 ([10.21.114.124]) by XMB-RCD-212.cisco.com ([72.163.62.219]) with Microsoft Exchange Server HTTP-DAV ; Sat, 18 Feb 2012 06:47:34 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Fri, 17 Feb 2012 22:47:34 -0800 From: snandaku To: "rtcweb@ietf.org" , "public-webrtc@w3.org" Message-ID: Thread-Topic: URI Scheme for TURN Configuration Thread-Index: Acztvisgg+aSg30roEqjs2l7hTwgaQASwZnZ In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3412363654_69311335" X-OriginalArrivalTime: 18 Feb 2012 06:47:35.0660 (UTC) FILETIME=[328512C0:01CCEE09] Subject: [rtcweb] URI Scheme for TURN Configuration 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, 18 Feb 2012 06:47:41 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3412363654_69311335 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hello All We have submitted a proposal to IETF BEHAVE WG on URI scheme representing TURN configuration. Draft can be retrieved at :( http://tools.ietf.org/html/draft-petithuguenin-behave-turn-uris-00) > =20 > We presented the idea at the BEHAVE interim today and it was positively > received. The BEHAVE chairs were interested in obtaining a signoff on cho= osing > URI scheme against proposals based on string representation or JSON for t= he > matter. We would like to get opinions and thoughts around this approach f= rom > RTCWeb/WebRTC chairs and the members. >=20 >=20 > Below we have summarized the motivation and some samples from the dra= ft > for a quick reference. >=20 > Motivation for the TURN URI Scheme in the context of RTCWeb > -TURN protocol is used to establish candidates to perform ICE > connectivity checks. > - Current proposal in the spec based on string representation has > inherent shortcomings and is not future proof (say ipv6:port scenarios) > - An URI scheme with well defined grammar SHALL help in the follo= wing > ways > Provide UNIVERSAL way to configure TURN Server > configuration to myriad of RTCWeb Clients/Web Applications > Enhance INTEROPERABILITY between implementations by > standardizing on the URI Scheme across > Different Browser Vendors, Different Web > Application Services, Gateways and alike. > Define STANDARD data representation format as enforce= d by > the URI scheme > Enable EVOLUTION and FUTURE PROOFING defined by the > encoding URI syntax grammar > Immediate BENEFITS can be realized from current propo= sals > for things like IPv6 support, Unicode user/password, > resolution mechanism, etc. >=20 > Sample URI > turn:example.org > turns:example.org:8189 > turn:example.org?transport=3Dudp >=20 > We did think about JSON as one possible approach but didn=B9t pursue > further for few reasons mentioned below > JSON is nice for web browser (theory), but it=B9s useful to kee= p in > mind that: >>> =B7 Just doing an eval on a JSON object is a bad idea, so it has = to >>> be parsed with parsing logic =AD no benefit in terms of processing >>> =B7 It=B9s harder for a human to compose a JSON object, but URIs ar= e >>> more widely understood >>> =B7 JavaScript is the popular language today, but Google and othe= rs >>> will come along with new programming languages (witness: DART) and then >>> what? Will JSON be as attractive? I suspect URIs will be. >>> =B7 We want this to be useful in places outside the browser, so J= SON >>> should not be the first thought >=20 >=20 > Apart from the above reasons, going with URI scheme will permit to simp= lify > the text in the W3C document by referencin RFC 5928 and the future TURN U= RI > RFC. That cannot be a bad thing. A third motivation is that as the TURN= URI > is done in a different WG, this permits to do this work in parallel to RT= CWEB > (that probably does not need more distractions). >=20 > RTCWeb impacts millions of end-points and we strongly believe providing > standard way to provision and configure TURN/STUN information would be re= ally > effective. >=20 >=20 >=20 > Please let us know your thoughts and support in this approach >=20 >=20 >=20 >=20 > Regards > Suhas Nandakumar > Marc Petit Huhuenin > Gonzalo Salgueiro > Paul E Jones --B_3412363654_69311335 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable URI Scheme for TURN Configuration Hello All

        We have submitted a proposa= l to IETF BEHAVE WG on URI scheme representing TURN configuration. Draft can= be retrieved at :( http://tools.ietf.org/html/dra= ft-petithuguenin-behave-turn-uris-00)
<= SPAN STYLE=3D'font-size:11pt'>       
 We presented the idea at the BEHAVE interim today and it was positive= ly received. The BEHAVE chairs were interested in obtaining a signoff on cho= osing  URI scheme against proposals based on string representation or J= SON for the matter. We would like to get opinions and thoughts around this a= pproach from RTCWeb/WebRTC chairs and the members.


    Below we have summarized the motivation and some sa= mples from the draft for a quick reference.

    Motivation for the TURN URI Scheme in the contex= t of RTCWeb
        -TURN protocol is  used= to establish candidates to perform ICE connectivity checks.
        - Current proposal in the s= pec based on string representation has inherent shortcomings and is not futu= re proof (say ipv6:port scenarios)
        - An URI scheme with well d= efined grammar SHALL help in the following ways
            &nb= sp;       Provide UNIVERSAL way to= configure TURN Server configuration to myriad of RTCWeb Clients/Web Applica= tions
            &nb= sp;       Enhance INTEROPERABILITY between implementations by standardizing on the URI Scheme across
            &nb= sp;            &= nbsp;      Different Browser Vendors, Differen= t Web Application Services, Gateways and alike.
            &nb= sp;       Define STANDARD data rep= resentation format as enforced by the URI scheme
            &nb= sp;       Enable EVOLUTION and = FUTURE PROOFING defined by the encoding URI syntax grammar
            &nb= sp;      Immediate  BENEFITS can be re= alized from current proposals for things like IPv6 support, Unicode user= /password,
            &nb= sp;       resolution mechanism, etc. &nbs= p;     

       Sample URI
           &nbs= p;   turn:example.org
            &nb= sp;   turns:example.org:8189
            &nb= sp;   turn:example.org?transport=3Dudp

     We did think about JSON as one possible appro= ach but didn’t pursue further for few reasons mentioned below
            JSO= N is nice for web browser (theory), but it’s useful to keep in mind th= at:
·     &nb= sp;   Just doing an eval on a JSON object is a bad idea, so i= t has to
be parsed with parsing logic – no benefit in terms of processing
·         It’s harder = for a human to compose a JSON object, but URIs are
more widely understood
·         JavaScript is the = popular language today, but Google and others
will come along with new programming languages (witness: DART) and then
what?  Will JSON be as attractive? I suspect URIs will be.
·         We want this to be= useful in places outside the browser, so JSON
should not be the first thought


  Apart from the above reasons, going with URI scheme will permit= to simplify the text in the W3C document by referencin RFC 5928 and the fut= ure TURN URI RFC.  That cannot be a bad thing.  A third motivation= is that as the TURN URI is done in a different WG, this permits to do this = work in parallel to RTCWEB (that probably does not need more distractions).<= BR>
 RTCWeb impacts millions of end-points and we strongly believe providi= ng standard way to provision and configure TURN/STUN information would be re= ally effective.



Please let us know your thoughts and support in this approach




Regards
Suhas Nandakumar
Marc Petit Huhuenin
Gonzalo Salgueiro
Paul E Jones
--B_3412363654_69311335-- From pravindran@sonusnet.com Sun Feb 19 09:53: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 37CE121F853B for ; Sun, 19 Feb 2012 09:53:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 wXFlTPV9uUao for ; Sun, 19 Feb 2012 09:52:59 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 9231521F8549 for ; Sun, 19 Feb 2012 09:52:59 -0800 (PST) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q1JHrjQo026655; Sun, 19 Feb 2012 12:53:45 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 19 Feb 2012 12:52:57 -0500 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 19 Feb 2012 23:23:09 +0530 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; Sun, 19 Feb 2012 23:23:08 +0530 From: "Ravindran, Parthasarathi" To: Cullen Jennings , "Hutton, Andrew" Thread-Topic: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case Thread-Index: AQHM7IE9KMJ367wTfUugOb7j2iGwS5Y/lw0AgAGhwICAA0qV0A== Date: Sun, 19 Feb 2012 17:53:07 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E040A1D@inba-mail01.sonusnet.com> References: <7F2072F1E0DE894DA4B517B93C6A05852C3D87E060@ESESSCMS0356.eemea.ericsson.se> <3CBDF06F-F52D-4C09-A78F-1A0D8479572A@iii.ca> <7F2072F1E0DE894DA4B517B93C6A05852C3D87E58F@ESESSCMS0356.eemea.ericsson.se> <101C6067BEC68246B0C3F6843BCCC1E31202EDA663@MCHP058A.global-ad.net> <15CD1ECE-6BDD-4EE0-AA5B-EF40616578CD@iii.ca> In-Reply-To: <15CD1ECE-6BDD-4EE0-AA5B-EF40616578CD@iii.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 19 Feb 2012 17:53:09.0385 (UTC) FILETIME=[5749AF90:01CCEF2F] Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case 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, 19 Feb 2012 17:53:00 -0000 Cullen, AFAIK, 18x with sendrecv as direction attribute & DTMF (telephony-event) is= allowed by couple of operators in FEDEX (call center) scenario. Andy will = be able to double confirm whether he also comes across the similar deployme= nt. Thanks Partha >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of Cullen Jennings >Sent: Saturday, February 18, 2012 2:29 AM >To: Hutton, Andrew >Cc: public-webrtc@w3.org; rtcweb@ietf.org >Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case > > >On Feb 16, 2012, at 1:04 PM, Hutton, Andrew wrote: > >>> (Also, in the FEDEX case, there could be scenarios where the browser >>> does need to transit media, if the user is e.g. promted for DTMFs, >>> voice commands etc...) >>> >> >> [AndyH] - I agree that media transmission is required at this stage so >that the user can navigate through voice prompts (E.g. via DTMF) I >thought this was the main requirement from the FEDEX use case. > >that's not my understanding. My understanding was it was one way media >until the final response in the early media case. And the IVR sends the >first prompt as ringtone but cuts over before two way media (IE DTMF) is >needed. The whole point of this hack is to cut the time the IVR gets >billed for but the SP is not going to provide two way media before >billing starts. > > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From pravindran@sonusnet.com Sun Feb 19 11:25: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 DB65F21F84DE for ; Sun, 19 Feb 2012 11:25:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8AIh6f4sj+jP for ; Sun, 19 Feb 2012 11:25:42 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id DFA2321F84D5 for ; Sun, 19 Feb 2012 11:25:41 -0800 (PST) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q1JJQRmU021640; Sun, 19 Feb 2012 14:26:27 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 19 Feb 2012 14:25:38 -0500 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 Feb 2012 00:55:50 +0530 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; Mon, 20 Feb 2012 00:55:50 +0530 From: "Ravindran, Parthasarathi" To: Cullen Jennings , Justin Uberti Thread-Topic: [rtcweb] Single offer with multiple answer handling in JSEP [was RE: New JSEP draft posted] Thread-Index: AQHM67gG55cr02A1XECJjPr/R3Q48ZY9oafAgAF6hICAAOnjAIABOnyAgANPUKA= Date: Sun, 19 Feb 2012 19:25:49 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E040B37@inba-mail01.sonusnet.com> References: <387F9047F55E8C42850AD6B3A7A03C6C0E03F8A4@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E03FAB5@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E03FB7C@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E03FC20@inba-mail01.sonusnet.com> <9ED4A9AC-37C7-4E6D-B6C6-4D3C9537B356@iii.ca> <387F9047F55E8C42850AD6B3A7A03C6C0E040130@inba-mail01.sonusnet.com> <935E62D2-61EB-4E53-98D7-E2BC78AC0B41@iii.ca> In-Reply-To: <935E62D2-61EB-4E53-98D7-E2BC78AC0B41@iii.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: multipart/mixed; boundary="_004_387F9047F55E8C42850AD6B3A7A03C6C0E040B37inbamail01sonus_" MIME-Version: 1.0 X-OriginalArrivalTime: 19 Feb 2012 19:25:50.0702 (UTC) FILETIME=[4A1750E0:01CCEF3C] Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] Single offer with multiple answer handling in JSEP [was RE: New JSEP draft posted] 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, 19 Feb 2012 19:25:44 -0000 --_004_387F9047F55E8C42850AD6B3A7A03C6C0E040B37inbamail01sonus_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cullen, As I mentioned below, the problem statement is for multiple answer and mult= iple 200 is one of the IETF SIP (RFC 3261) defined multiple answer usecase.= Deployed (real) SIP world usecase for multiple answer exists in form of 18= x with answer1 and 2xx with answer2 for INVITE offer. I worked/interoped wi= th multiple well deployed implementation which supports "receiving" multipl= e answer with slight different variance (and no UPDATE [RFC 3311] in the mi= ddle) and I'm sure more implementation exists. The reason for allowing "rec= eiving" multiple answer is leniency while receiving the SIP message which i= s generally accepted in Product development. Even though some of the deploy= ed implementation violates RFC 3264 for the noble reason of reducing the nu= mber of SIP messages (no UPDATE Offer/answer transaction after 18x) for the= basic call, it is possible to make those implementation SIP RFC compliance= by changing 18x To-Tag, Please look into "18x with SDP and 2xx with differ= ent SDP & To Tag" attachment for more details.=20 Also, 18x with SDP and 2xx without SDP is the another set implementation ex= ists as mentioned in "18x with SDP and 2xx without SDP" attachment. In case= these details are not enough, I'll add Multiple 18x with different 2xx cal= lflow later. Keeping aside SIP deployment, I'm still not convinced why browser MUST be r= estricted from multiple answer as I didn't see the technical reason for res= tricting. As I mentioned, Fixed-Mobile application is possible to implement= using this mechanism and WebRTC shall provide the building block for it. = The callflow is shown in "Single Offer Multiple Answer callflow" example. AFAIK, offer results in RTP port allocation in the resource manager and SRT= P key generation. In case first answer is received, those resources are req= uired irrespective of multiple answer will receive or not. In case your arg= ument is about pre-allocated (RSVP kind of) bandwidth for offer, those spec= ific WebRTC applications are free to reject the second answer onwards and c= onsider first answer as the final answer, so this proposal in not limiting = those applications. Could you please clarify any other list of resources l= ock/leak in your mind due to offer for my understanding. I'm asking this qu= ery as I get the feeling from other mail threads that resource lock/leak is= one of the reason for requesting final answer by you. Justin, I have added 3 callflow as a starting point for the discussion which shall = be added later in case consensus is reached. I'll provide multiple 18x with= different order 2xx later. Thanks Partha >-----Original Message----- >From: Cullen Jennings [mailto:fluffy@iii.ca] >Sent: Saturday, February 18, 2012 2:51 AM >To: Justin Uberti >Cc: Ravindran, Parthasarathi; rtcweb@ietf.org; public-webrtc@w3.org >Subject: Re: [rtcweb] Single offer with multiple answer handling in JSEP >[was RE: New JSEP draft posted] > > >I'm most interested in real world use cases which if they were being >done with SIP would result in multiple 200 being processed by the >browser. I have not got my head around why this would be needed yet and >without the use cases I'm having a hard time deciding if there is a >problem or not. > > >On Feb 16, 2012, at 7:35 PM, Justin Uberti wrote: > >> Agree it has not been addressed. I'm having some trouble understanding >the exact flows that we need to address here (multiple 2xx, multiple 18x >followed by 2xx, multiple 18x followed by multiple 2xx) but if I >understand correctly your suggestion was: >> >> 1) allow a setRemoteDesc(SDP_ANSWER) to follow a >> setRemoteDesc(SDP_ANSWER) >> 2) document that in this case (multiple 2xx), the JS is responsible >for sending BYE to the previous answerer. >> >> which sounds totally reasonable to me. >> >> If this sounds good to you, would you mind sketching out a call flow >that I could include in the examples section? >> >> On Thu, Feb 16, 2012 at 2:11 AM, Ravindran, Parthasarathi > wrote: >> Cullen/Justin, >> >> Single offer with multiple answer open item is not addressed in -02 >version of JSEP draft. Hope you first agree this as an open item in >JSEP. >> >> Thanks >> Partha >> >> >-----Original Message----- >> >From: Ravindran, Parthasarathi >> >Sent: Wednesday, February 15, 2012 2:43 PM >> >To: 'Cullen Jennings' >> >Cc: Justin Uberti; rtcweb@ietf.org; public-webrtc@w3.org >> >Subject: RE: [rtcweb] Single offer with multiple answer handling in >> >JSEP [was RE: New JSEP draft posted] >> > >> >Cullen, >> > >> >RFC3261 references for receiving multiple 2xx in UAC which does not >> >fork INVITE are as follows: >> > >> > >> >Sec 13.1 Para 3: >> > >> >Therefore, when multiple 2xx responses are received from different >> >remote UAs (because the INVITE forked), each 2xx establishes a >> >different dialog. All these dialogs are part of the same call. >> > >> >Sec 13.2.2.4 2xx Responses >> > >> > Multiple 2xx responses may arrive at the UAC for a single INVITE >> > request due to a forking proxy. Each response is distinguished by >> > the tag parameter in the To header field, and each represents a >> > distinct dialog, with a distinct dialog identifier. >> > >> > If, after acknowledging any 2xx response to an INVITE, the UAC >does >> > not want to continue with that dialog, then the UAC MUST terminate >> > the dialog by sending a BYE request as described in Section 15. >> > >> > >> >As per the last statements, it is upto the SIP application to decide >> >which one of the final 2xx response has to be included within the >call. >> >The usecase 3 is based on RFC3262 (PRACK) support wherein it is >> >possible to receive multiple forked 18x with SDP followed by 2xx with >> >or without SDP and SIP 2xx response is not tied to offer/answer >exchange. >> > >> >I have provided mobile to desktop as an example to justify the last >> >answer may be used in the offer in some JS application. As I >> >mentioned below, there is no need to restrict updating latest answer >> >for an offer in terms of API and protocol. >> > >> >Thanks >> >Partha >> > >> >>-----Original Message----- >> >>From: Cullen Jennings [mailto:fluffy@iii.ca] >> >>Sent: Wednesday, February 15, 2012 1:31 PM >> >>To: Ravindran, Parthasarathi >> >>Cc: Justin Uberti; rtcweb@ietf.org; public-webrtc@w3.org >> >>Subject: Re: [rtcweb] Single offer with multiple answer handling in >> >>JSEP [was RE: New JSEP draft posted] >> >> >> >> >> >>I'm a bit lost on use case in SIP context - assuming that the UAC >> >>did not fork but that a proxy or B2BUA did the forking, it seems >> >>like the UAC should never receive more than one final response. >> >> >> >>In the case of moving from desktop to mobile, it seems like that is >> >>updating the stream and would use a call flow more like update >> >>examples in the draft instead of trying to reuse some old answer. >> >> >> >> >> >>On Feb 14, 2012, at 11:24 , Ravindran, Parthasarathi wrote: >> >> >> >>> Justin, >> >>> >> >>> Some of the usecases could be >> >>> 1) The same user of a website signed-in in the multiples >devices >> >>and acts as answerer, the session establishment request to the >> >>identity will alert all the signed-in devices and it is possible >> >>that multiple devices answer to the session. Here, user may move >> >>from one device >> >>(mobile) to another device (desktop) within the session and wishes >> >>to continue the session with the last answer. Please note that >> >>website is flexible to provide this service. >> >>> 2) RFC 3261 SIP UA offer/answer handling w.r.t INVITE with >SDP >> >to >> >>multiple 2xx with SDP handling scenario using JSEP >> >>> 3) Another SIP usecase could be multiple 18x responses with >SDP >> >>for INVITE with SDP and multiple 2xx responses without SDP but order >> >>within 18x and 200 are not same. Say 2xx of the second 18x is >> >>received as the first 2xx. Here, we need to know how second 18x is >> >>handled and also, the subsequent 2xx is handled. >> >>> >> >>> Of course, it is possible to build more usecases around this area. >> >>> As >> >>we made signaling outside the scope of WebRTC, it is upto JS >> >>application to decide the order in which offer/answer happens. I'm >> >>not relating offer/answer FSM with session establishment state like >> >>18x, 2xx but I'm interested in knowing browser media plane behavior >> >>in different state of offer/answer handling by which JS application >> >>behaves consistently in all browsers. >> >>> >> >>> Thanks >> >>> Partha >> >>> >> >>> >> >>> From: Justin Uberti [mailto:juberti@google.com] >> >>> Sent: Tuesday, February 14, 2012 11:36 PM >> >>> To: Ravindran, Parthasarathi >> >>> Cc: rtcweb@ietf.org; public-webrtc@w3.org >> >>> Subject: Re: Single offer with multiple answer handling in JSEP >> >>> [was >> >>RE: [rtcweb] New JSEP draft posted] >> >>> >> >>> Partha, >> >>> >> >>> I need more information about the use case to provide an accurate >> >>response. As mentioned in my earlier mail, are both answers 2xx >> >>responses? >> >>> >> >>> On Tue, Feb 14, 2012 at 12:17 PM, Ravindran, Parthasarathi >> >> wrote: >> >>> Hi Justin, >> >>> >> >>> In this mail thread, Let us define the behavior of multiple >> >>> (atleast >> >>two) answers for the single offer in WebRTC browser. Now, Please >> >>let me know your opinion for my below mail. >> >>> >> >>> Thanks >> >>> Partha >> >>> >> >>> From: Justin Uberti [mailto:juberti@google.com] >> >>> Sent: Tuesday, February 14, 2012 9:47 PM >> >>> >> >>> To: Ravindran, Parthasarathi >> >>> Cc: rtcweb@ietf.org; public-webrtc@w3.org >> >>> Subject: Re: Single offer with multiple answer handling in JSEP >> >>> [was >> >>RE: [rtcweb] New JSEP draft posted] >> >>> >> >>> >> >>> >> >>> On Tue, Feb 14, 2012 at 6:39 AM, Ravindran, Parthasarathi >> >> wrote: >> >>> Hi Justin, >> >>> >> >>> It will be good to mention in the JSEP draft that multiple >> >>> answers >> >>for single offer will not lead to RTP Mixing and WebRTC client acts >> >>as RTP Endpoint. >> >>> >> >>> Failing the second Answer will be limiting the provision in RFC >> >>> 3264 >> >>offer/answer itself as RFC 3264 supports single offer with multiple >> >>answer. Also, it is better to define the behavior in API rather than >> >>putting this scenario in the browser implementation specific. In >> >>simple scenarios (like alerting with one answer, connect with second >> >>answer), replacing the previous ANSWER will be expected behavior. >> >>This may not be desired behavior in case two connect responses from >> >>different WebRTC clients received with different answers but there >> >>is no other alternative solution possible without mixing. >> >>> >> >>> Do you need to support 2 final answers, or would the provisional >> >>answer support provided via SDP_PRANSWER work for you? >> >>> >> >>> IMO, it is better to define it explicitly in JSEP that "latest >> >>> ANSWER >> >>to the offer will replace the existing answer is the expected >> >>behavior ". Also, Please mentioned that JS application is >responsible for >> >>discarding (terminating) previous ANSWER notification. Please let >me >> >>your opinion on this closure. >> >>> >> >>> Thanks >> >>> Partha >> >>> >> >>> From: Justin Uberti [mailto:juberti@google.com] >> >>> Sent: Tuesday, February 14, 2012 7:29 PM >> >>> To: Ravindran, Parthasarathi >> >>> Cc: rtcweb@ietf.org; public-webrtc@w3.org >> >>> Subject: Re: Single offer with multiple answer handling in JSEP >> >>> [was >> >>RE: [rtcweb] New JSEP draft posted] >> >>> >> >>> Regarding your previous mail, an ANSWER after an ANSWER would >> >>> either >> >>fail (if we wanted to simplify), or replace the previous ANSWER >> >>(essentially the same as if you had done setLocalDescription(OFFER, >> >>localDescription) followed by setRemoteDescription(ANSWER, answer2). >> >>> >> >>> In no case would it mix the descriptions/media from both answers. >> >>> >> >>> Other comments inline below. >> >>> >> >>> On Tue, Feb 14, 2012 at 1:24 AM, Ravindran, Parthasarathi >> >> wrote: >> >>> Hi Justin, >> >>> >> >>> Adding to my earlier mail, In case answer2 SDP is updated in >> >>> offerer1 >> >>browser without notifying answerer1, then answer1 will continue to >> >>transmit RTP which may not be desired behavior. IMO, we need to >> >>define this behavior clearly in offerer side. Some of the possible >> >>solutions are >> >>> >> >>> 1) offerer1 has to send atleast RTCP BYE packets towards >> >>answerer1 while accepting the answerer2 SDP. >> >>> >> >>> 2) Throw callback to clear answer1 SDP towards offererJS. >> >>> >> >>> >> >>> The application which called setRemoteDescription twice should >> >>> have >> >>the best idea about what is going on, and therefore is responsible >> >>for notifying answerer1 that its answer has been discarded, if it >> >>makes sense to do so. No callback should be needed here. >> >>> >> >>> >> >>> Please let me know your opinion here. >> >>> >> >>> Thanks >> >>> Partha >> >>> >> >>> From: Ravindran, Parthasarathi >> >>> Sent: Tuesday, February 14, 2012 12:07 AM >> >>> To: 'Justin Uberti'; rtcweb@ietf.org; public-webrtc@w3.org >> >>> Subject: Single offer with multiple answer handling in JSEP [was >RE: >> >>[rtcweb] New JSEP draft posted] >> >>> >> >>> Hi Justin, >> >>> >> >>> In the draft, it is not spelled out explicitly what is the >> >>> expected >> >>behavior in offerer browser in case multiple answer is received for >> >>single offer. Offer/answer exchange in offerer is as follows: >> >>> >> >>> OffererJS->OffererUA: var offer =3D pc.createOffer(null); >> >>> OffererJS->OffererUA: pc.setLocalDescription(SDP_OFFER, offer); >> >>> OffererJS->OffererUA: pc.setRemoteDescription(SDP_ANSWER, >> >>> OffererJS->answer1); >> >>> OffererUA->Answerer1UA: >> >>> OffererJS->OffererUA: pc.setRemoteDescription(SDP_ANSWER, >> >>> OffererJS->answer2); >> >>> OffererUA->Answerer?UA: ? >> >>> >> >>> My understanding is that "answer2" will update "answer1" in >> >>> browser >> >>and starting sending/receiving media towards answer2 media IP and >port. >> >>Could you please explain the expected behavior in offerer browser >> >>whether it updates the media stream based on the last answer or >> >>mixes both answerer. >> >>> >> >>> Thanks >> >>> Partha >> >>> >> >>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >> >>Behalf Of Justin Uberti >> >>> Sent: Thursday, February 09, 2012 2:27 AM >> >>> To: rtcweb@ietf.org; public-webrtc@w3.org >> >>> Subject: [rtcweb] New JSEP draft posted >> >>> >> >>> Now available at http://www.ietf.org/id/draft-uberti-rtcweb-jsep- >> >>01.txt >> >>> >> >>> Includes changes based on implementation feedback, and I believe >> >>> it >> >>addresses most of the concerns raised in last week's interim >meetings: >> >>> - Initial documentation provided for each API call, and what state >> >>changes it causes >> >>> - More examples, including a complete basic sample application >> >>> - Simplified approach to trickle candidate handling >> >>> - Resolved concerns about how to separate SDP attributes into >> >>> media / >> >>transport >> >>> - Provided encapsulation for SDP blobs and ICE candidate lines, in >> >>> the >> >>event we want to change encodings or provide helper functions for JS >> >>> - Provided mechanism for limiting candidates to TURN-only >> >>> - Resolved several implementation issues >> >>> >> >>> I have not yet addressed the non-overlapping codec concern >> >>> mentioned >> >>in the interim meeting. I think there are ways of handling this >> >>either in the application or the implementation, but I wanted to get >> >>this -01 out first for feedback. >> >>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> rtcweb mailing list >> >>> rtcweb@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/rtcweb >> >> --_004_387F9047F55E8C42850AD6B3A7A03C6C0E040B37inbamail01sonus_ Content-Type: text/plain; name="Single Offer Multiple answer callflow.txt" Content-Description: Single Offer Multiple answer callflow.txt Content-Disposition: attachment; filename="Single Offer Multiple answer callflow.txt"; size=2752; creation-date="Sat, 18 Feb 2012 17:22:50 GMT"; modification-date="Sun, 19 Feb 2012 18:21:30 GMT" Content-Transfer-Encoding: base64 VGhpcyBleGFtcGxlIGRlbW9uc3RyYXRlcyBtdWx0aXBsZSBhbnN3ZXIgZm9yIHNpbmdsZSBvZmZl ciwgd2l0aG91dCB0aGUgdXNlIG9mIHRyaWNrbGUNCiAgIGNhbmRpZGF0ZXMNCg0KICAgLy8gQ2Fs bCBpcyBpbml0aWF0ZWQgdG93YXJkIEFuc3dlcmVyDQogICBPZmZlcmVySlMtPk9mZmVyZXJVQTog ICBwYyA9IG5ldyBQZWVyQ29ubmVjdGlvbigpOw0KICAgT2ZmZXJlckpTLT5PZmZlcmVyVUE6ICAg cGMuYWRkU3RyZWFtKGxvY2FsU3RyZWFtLCBudWxsKTsNCiAgIE9mZmVyZXJKUy0+T2ZmZXJlclVB OiAgIHBjLnN0YXJ0SWNlKCk7DQogICBPZmZlcmVyVUEtPk9mZmVyZXJKUzogICBpY2VDYWxsYmFj ayhjYW5kaWRhdGUsIGZhbHNlKTsNCiAgIE9mZmVyZXJKUy0+T2ZmZXJlclVBOiAgIG9mZmVyID0g cGMuY3JlYXRlT2ZmZXIobnVsbCk7DQogICBPZmZlcmVySlMtPk9mZmVyZXJVQTogICBwYy5zZXRM b2NhbERlc2NyaXB0aW9uKFNEUF9PRkZFUiwgb2ZmZXIudG9TZHAoKSk7DQogICBPZmZlcmVySlMt PkFuc3dlcmVySlM6ICB7InR5cGUiOiJPRkZFUiIsICJzZHAiOiI8b2ZmZXI+In0NCg0KICAgLy8g T0ZGRVIgYXJyaXZlcyBhdCBBbnN3ZXJlcjENCiAgIEFuc3dlcmVyMUpTLT5BbnN3ZXJlcjFVQTog cGMgPSBuZXcgUGVlckNvbm5lY3Rpb24oKTsNCiAgIEFuc3dlcmVyMUpTLT5BbnN3ZXJlcjFVQTog cGMuc2V0UmVtb3RlRGVzY3JpcHRpb24oU0RQX09GRkVSLCBtc2cuc2RwKTsNCiAgIEFuc3dlcmVy MVVBLT5BbnN3ZXJlcjFKUzogb25hZGRzdHJlYW0ocmVtb3RlU3RyZWFtKTsNCiAgIEFuc3dlcmVy MUpTLT5BbnN3ZXJlcjFVQTogcGMuc3RhcnRJY2UoKTsNCiAgIEFuc3dlcmVyMVVBLT5PZmZlcmVy VUE6ICBpY2VDYWxsYmFjayhjYW5kaWRhdGUxLCBmYWxzZSk7DQoNCiAgIC8vIE9GRkVSIGFycml2 ZXMgYXQgQW5zd2VyZXIyDQogICBBbnN3ZXJlcjJKUy0+QW5zd2VyZXIyVUE6IHBjID0gbmV3IFBl ZXJDb25uZWN0aW9uKCk7DQogICBBbnN3ZXJlcjJKUy0+QW5zd2VyZXIyVUE6IHBjLnNldFJlbW90 ZURlc2NyaXB0aW9uKFNEUF9PRkZFUiwgbXNnLnNkcCk7DQogICBBbnN3ZXJlcjJVQS0+QW5zd2Vy ZXIySlM6IG9uYWRkc3RyZWFtKHJlbW90ZVN0cmVhbSk7DQogICBBbnN3ZXJlcjJKUy0+QW5zd2Vy ZXIyVUE6IHBjLnN0YXJ0SWNlKCk7DQogICBBbnN3ZXJlcjJVQS0+T2ZmZXJlclVBOiAgaWNlQ2Fs bGJhY2soY2FuZGlkYXRlMiwgZmFsc2UpOw0KDQogICAvLyBBbnN3ZXJlcjEgYWNjZXB0cyBjYWxs DQogICBBbnN3ZXJlcjFKUy0+QW5zd2VyZXIxVUE6IHBlZXIuYWRkU3RyZWFtKGxvY2FsU3RyZWFt LCBudWxsKTsNCiAgIEFuc3dlcmVyMUpTLT5BbnN3ZXJlcjFVQTogYW5zd2VyMSA9IHBlZXIuY3Jl YXRlQW5zd2VyKG1zZy5vZmZlciwgbnVsbCk7DQogICBBbnN3ZXJlcjFKUy0+QW5zd2VyZXIxVUE6 IHBlZXIuc2V0TG9jYWxEZXNjcmlwdGlvbihTRFBfQU5TV0VSLCBhbnN3ZXIxKTsNCiAgIEFuc3dl cmVyMUpTLT5PZmZlcmVySlM6ICB7InR5cGUiOiJBTlNXRVIiLCJzZHAiOiI8YW5zd2VyMT4ifQ0K DQogICAvLyBBTlNXRVIxIGFycml2ZXMgYXQgT2ZmZXJlcg0KICAgT2ZmZXJlckpTLT5PZmZlcmVy VUE6ICAgcGVlci5zZXRSZW1vdGVEZXNjcmlwdGlvbihBTlNXRVIsIGFuc3dlcjEpOyANCiAgIE9m ZmVyZXJVQS0+T2ZmZXJlckpTOiAgIG9uYWRkc3RyZWFtKHJlbW90ZVN0cmVhbSk7DQoNCiAgIC8v IElDRSBDb21wbGV0ZXMgKGF0IEFuc3dlcmVyKQ0KICAgQW5zd2VyZXIxVUEtPkFuc3dlcmVyMUpT OiBvbm9wZW4oKTsNCiAgIEFuc3dlcmVyMVVBLT5PZmZlcmVyVUE6ICBNZWRpYQ0KDQoNCiAgIC8v IElDRSBDb21wbGV0ZXMgKGF0IE9mZmVyZXIpDQogICBPZmZlcmVyVUEtPk9mZmVyZXJKUzogICBv bm9wZW4oKTsNCiAgIE9mZmVyZXJKUy0+QW5zd2VyZXIxSlM6ICB7InR5cGUiOiJPSyIgfQ0KICAg T2ZmZXJlclVBLT5BbnN3ZXJlcjFVQTogIE1lZGlhDQoNCg0KICAgLy8gQW5zd2VyZXIyIGFjY2Vw dHMgY2FsbA0KICAgQW5zd2VyZXIySlMtPkFuc3dlcmVyMlVBOiBwZWVyLmFkZFN0cmVhbShsb2Nh bFN0cmVhbSwgbnVsbCk7DQogICBBbnN3ZXJlcjJKUy0+QW5zd2VyZXIyVUE6IGFuc3dlcjEgPSBw ZWVyLmNyZWF0ZUFuc3dlcihtc2cub2ZmZXIsIG51bGwpOw0KICAgQW5zd2VyZXIySlMtPkFuc3dl cmVyMlVBOiBwZWVyLnNldExvY2FsRGVzY3JpcHRpb24oU0RQX0FOU1dFUiwgYW5zd2VyMik7DQog ICBBbnN3ZXJlcjJKUy0+T2ZmZXJlckpTOiAgeyJ0eXBlIjoiQU5TV0VSIiwic2RwIjoiPGFuc3dl cjI+In0NCg0KICAgLy8gQU5TV0VSMiBhcnJpdmVzIGF0IE9mZmVyZXINCiAgIE9mZmVyZXJKUy0+ T2ZmZXJlclVBOiAgIHBlZXIuc2V0UmVtb3RlRGVzY3JpcHRpb24oQU5TV0VSLCBhbnN3ZXIyKTsg DQogICBPZmZlcmVyVUEtPk9mZmVyZXJKUzogICBvbmFkZHN0cmVhbShyZW1vdGVTdHJlYW0pOw0K ICAgT2ZmZXJlckpTLT5BbnN3ZXJlcjFKUzogIEJZRQ0KDQoNCiAgIC8vIElDRSBDb21wbGV0ZXMg KGF0IEFuc3dlcmVyMikNCiAgIEFuc3dlcmVyMlVBLT5BbnN3ZXJlcjJKUzogb25vcGVuKCk7DQog ICBBbnN3ZXJlcjJVQS0+T2ZmZXJlclVBOiAgTWVkaWENCg0KDQogICAvLyBJQ0UgQ29tcGxldGVz IChhdCBPZmZlcmVyKQ0KICAgT2ZmZXJlclVBLT5PZmZlcmVySlM6ICAgb25vcGVuKCk7DQogICBP ZmZlcmVySlMtPkFuc3dlcmVyMkpTOiAgeyJ0eXBlIjoiT0siIH0NCiAgIE9mZmVyZXJVQS0+QW5z d2VyZXIyVUE6ICBNZWRpYQ== --_004_387F9047F55E8C42850AD6B3A7A03C6C0E040B37inbamail01sonus_ Content-Type: text/plain; name="18x with SDP and 2xx without SDP.txt" Content-Description: 18x with SDP and 2xx without SDP.txt Content-Disposition: attachment; filename="18x with SDP and 2xx without SDP.txt"; size=1222; creation-date="Sat, 18 Feb 2012 17:39:30 GMT"; modification-date="Sun, 19 Feb 2012 18:12:08 GMT" Content-Transfer-Encoding: base64 IEhhbmRsaW5nIDE4eCB3aXRoIFNEUCBhbmQgMnh4IHdpdGhvdXQgU0RQLCB1c2luZyBTSVANCg0K ICAgVGhpcyBleGFtcGxlIGRlbW9uc3RyYXRlcyBob3cgMTh4IHdpdGggU0RQIGNvdWxkIGJlIGhh bmRsZWQ7IGZvcg0KICAgc2ltcGxpY2l0eSwgb25seSB0aGUgb2ZmZXJlciBzaWRlIG9mIHRoZSBj YWxsIGlzIHNob3duLg0KDQogICAvLyBDYWxsIGlzIGluaXRpYXRlZCB0b3dhcmQgQW5zd2VyZXIN CiAgIE9mZmVyZXJKUy0+T2ZmZXJlclVBOiAgIHBjID0gbmV3IFBlZXJDb25uZWN0aW9uKCk7DQog ICBPZmZlcmVySlMtPk9mZmVyZXJVQTogICBwYy5hZGRTdHJlYW0obG9jYWxTdHJlYW0sIG51bGwp Ow0KICAgT2ZmZXJlckpTLT5PZmZlcmVyVUE6ICAgcGMuc3RhcnRJY2UoKTsNCiAgIE9mZmVyZXJV QS0+T2ZmZXJlckpTOiAgIGljZUNhbGxiYWNrKGNhbmRpZGF0ZSwgZmFsc2UpOw0KICAgT2ZmZXJl ckpTLT5PZmZlcmVyVUE6ICAgb2ZmZXIgPSBwYy5jcmVhdGVPZmZlcihudWxsKTsNCiAgIE9mZmVy ZXJKUy0+T2ZmZXJlclVBOiAgIHBjLnNldExvY2FsRGVzY3JpcHRpb24oU0RQX09GRkVSLCBvZmZl cik7DQogICBPZmZlcmVySlM6ICAgICAgICAgICAgICBzaXAgPSBjcmVhdGVJbnZpdGUob2ZmZXIp Ow0KICAgT2ZmZXJlckpTLT5BbnN3ZXJlckpTOiAgU0lQIElOVklURSB3LyBTRFANCg0KICAgLy8g MTgwIFJpbmdpbmcgaXMgcmVjZWl2ZWQgYnkgb2ZmZXJlciwgdy8gU0RQDQogICBPZmZlcmVySlM6 ICAgICAgICAgICAgICBhbnN3ZXIgPSBwYXJzZVJlc3BvbnNlKHNpcCk7DQogICBPZmZlcmVySlMt Pk9mZmVyZXJVQTogICBwYy5zZXRSZW1vdGVEZXNjcmlwdGlvbihTRFBfUFJBTlNXRVIsIGFuc3dl cik7DQogICBPZmZlcmVyVUEtPk9mZmVyZXJKUzogICBvbmFkZHN0cmVhbShyZW1vdGVTdHJlYW0p Ow0KDQogICAvLyBJQ0UgQ29tcGxldGVzIChhdCBPZmZlcmVyKQ0KICAgT2ZmZXJlclVBLT5PZmZl cmVySlM6ICAgb25vcGVuKCk7DQogICBPZmZlcmVyVUEtPkFuc3dlcmVyVUE6ICBNZWRpYQ0KDQog ICAvLyAyMDAgT0sgYXJyaXZlcyBhdCBPZmZlcmVyDQogICBPZmZlcmVySlM6ICAgICAgICAgICAg ICBhbnN3ZXIgPSBwYXJzZVJlc3BvbnNlKHNpcCk7DQogICBPZmZlcmVySlMtPk9mZmVyZXJVQTog ICBwYy5zZXRSZW1vdGVEZXNjcmlwdGlvbihTRFBfQU5TV0VSLCBhbnN3ZXIpOw0KICAgT2ZmZXJl ckpTLT5BbnN3ZXJlckpTOiAgQUNLDQoNCg== --_004_387F9047F55E8C42850AD6B3A7A03C6C0E040B37inbamail01sonus_ Content-Type: text/plain; name="18x with SDP and 2xx with different SDP.txt" Content-Description: 18x with SDP and 2xx with different SDP.txt Content-Disposition: attachment; filename="18x with SDP and 2xx with different SDP.txt"; size=1486; creation-date="Sun, 19 Feb 2012 18:11:39 GMT"; modification-date="Sun, 19 Feb 2012 18:24:41 GMT" Content-Transfer-Encoding: base64 SGFuZGxpbmcgMTh4IHdpdGggU0RQIGFuZCAyeHggd2l0aG91dCBTRFAsIHVzaW5nIFNJUA0KDQog ICBUaGlzIGV4YW1wbGUgZGVtb25zdHJhdGVzIGhvdyAxOHggd2l0aCBTRFAgY291bGQgYmUgaGFu ZGxlZDsgZm9yDQogICBzaW1wbGljaXR5LCBvbmx5IHRoZSBvZmZlcmVyIHNpZGUgb2YgdGhlIGNh bGwgaXMgc2hvd24uDQoNCiAgIC8vIENhbGwgaXMgaW5pdGlhdGVkIHRvd2FyZCBBbnN3ZXJlcg0K ICAgT2ZmZXJlckpTLT5PZmZlcmVyVUE6ICAgcGMgPSBuZXcgUGVlckNvbm5lY3Rpb24oKTsNCiAg IE9mZmVyZXJKUy0+T2ZmZXJlclVBOiAgIHBjLmFkZFN0cmVhbShsb2NhbFN0cmVhbSwgbnVsbCk7 DQogICBPZmZlcmVySlMtPk9mZmVyZXJVQTogICBwYy5zdGFydEljZSgpOw0KICAgT2ZmZXJlclVB LT5PZmZlcmVySlM6ICAgaWNlQ2FsbGJhY2soY2FuZGlkYXRlLCBmYWxzZSk7DQogICBPZmZlcmVy SlMtPk9mZmVyZXJVQTogICBvZmZlciA9IHBjLmNyZWF0ZU9mZmVyKG51bGwpOw0KICAgT2ZmZXJl ckpTLT5PZmZlcmVyVUE6ICAgcGMuc2V0TG9jYWxEZXNjcmlwdGlvbihTRFBfT0ZGRVIsIG9mZmVy KTsNCiAgIE9mZmVyZXJKUzogICAgICAgICAgICAgIHNpcCA9IGNyZWF0ZUludml0ZShvZmZlcik7 DQogICBPZmZlcmVySlMtPkFuc3dlcmVySlM6ICBTSVAgSU5WSVRFIHcvIFNEUA0KDQogICAvLyAx ODAgUmluZ2luZyBpcyByZWNlaXZlZCBieSBvZmZlcmVyLCB3L1NEUDENCiAgIE9mZmVyZXJKUzog ICAgICAgICAgICAgIGFuc3dlcjEgPSBwYXJzZVJlc3BvbnNlKHNpcCk7DQogICBPZmZlcmVySlMt Pk9mZmVyZXJVQTogICBwYy5zZXRSZW1vdGVEZXNjcmlwdGlvbihTRFBfQU5TV0VSLCBhbnN3ZXIx KTsNCiAgIE9mZmVyZXJVQS0+T2ZmZXJlckpTOiAgIG9uYWRkc3RyZWFtKHJlbW90ZVN0cmVhbSk7 DQoNCiAgIC8vIElDRSBDb21wbGV0ZXMgKGF0IE9mZmVyZXIpDQogICBPZmZlcmVyVUEtPk9mZmVy ZXJKUzogICBvbm9wZW4oKTsNCiAgIE9mZmVyZXJKUy0+QW5zd2VyZXIxSlM6ICB7InR5cGUiOiJP SyIgfQ0KICAgT2ZmZXJlclVBLT5BbnN3ZXJlcjFVQTogIE1lZGlhDQoNCiAgIC8vIDIwMCBPSyBh cnJpdmVzIGF0IE9mZmVyZXIsIHcvc2RwMiBhbmQgZGlmZmVyZW50IFRPIHRhZw0KICAgT2ZmZXJl ckpTOiAgICAgICAgICAgICAgYW5zd2VyMiA9IHBhcnNlUmVzcG9uc2Uoc2lwKTsNCiAgIE9mZmVy ZXJKUy0+T2ZmZXJlclVBOiAgIHBjLnNldFJlbW90ZURlc2NyaXB0aW9uKFNEUF9BTlNXRVIsIGFu c3dlcjIpOw0KICAgT2ZmZXJlckpTLT5BbnN3ZXJlcjJKUzogIEFDSw0KICAgT2ZmZXJlckpTLT5B bnN3ZXJlcjFKUzogIEJZRQ0KDQoNCiAgIC8vIElDRSBDb21wbGV0ZXMgKGF0IE9mZmVyZXIpDQog ICBPZmZlcmVyVUEtPk9mZmVyZXJKUzogICBvbm9wZW4oKTsNCiAgIE9mZmVyZXJKUy0+QW5zd2Vy ZXIySlM6ICB7InR5cGUiOiJPSyIgfQ0KICAgT2ZmZXJlclVBLT5BbnN3ZXJlcjJVQTogIE1lZGlh DQoNCg== --_004_387F9047F55E8C42850AD6B3A7A03C6C0E040B37inbamail01sonus_-- From ibc@aliax.net Sun Feb 19 11:54: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 79AB121F84B3 for ; Sun, 19 Feb 2012 11:54:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[AWL=0.067, 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 6nifQFoVCx2N for ; Sun, 19 Feb 2012 11:54:48 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id E087D21F84B4 for ; Sun, 19 Feb 2012 11:54:47 -0800 (PST) Received: by vcbfk14 with SMTP id fk14so3694419vcb.31 for ; Sun, 19 Feb 2012 11:54:47 -0800 (PST) Received-SPF: pass (google.com: domain of ibc@aliax.net designates 10.52.95.37 as permitted sender) client-ip=10.52.95.37; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ibc@aliax.net designates 10.52.95.37 as permitted sender) smtp.mail=ibc@aliax.net Received: from mr.google.com ([10.52.95.37]) by 10.52.95.37 with SMTP id dh5mr8271227vdb.88.1329681287478 (num_hops = 1); Sun, 19 Feb 2012 11:54:47 -0800 (PST) Received: by 10.52.95.37 with SMTP id dh5mr6617814vdb.88.1329681287207; Sun, 19 Feb 2012 11:54:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.203.2 with HTTP; Sun, 19 Feb 2012 11:54:27 -0800 (PST) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sun, 19 Feb 2012 20:54:27 +0100 Message-ID: To: snandaku Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlyCSfqgBSIeeTiunTbEf2j/DW5GQw2tr7s8vIcG4FnxQ2iziY3gh9lGK9qIFwNCwRMRfbl Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] URI Scheme for TURN Configuration 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, 19 Feb 2012 19:54:48 -0000 2012/2/17 snandaku : > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0We want this to be useful= in places outside the browser, so JSON > should not be the first thought Right. I expect that future applications running in smartphones could make usage of WebRTC capabilities out of the context of the WWW. --=20 I=C3=B1aki Baz Castillo From andrew.hutton@siemens-enterprise.com Sun Feb 19 13:25:55 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 118AA21F84DE for ; Sun, 19 Feb 2012 13:25:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, 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 Sdvocf-t1Xnl for ; Sun, 19 Feb 2012 13:25:54 -0800 (PST) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 3ADF321F84D7 for ; Sun, 19 Feb 2012 13:25:54 -0800 (PST) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id B430223F0453; Sun, 19 Feb 2012 22:25:52 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Sun, 19 Feb 2012 22:25:52 +0100 From: "Hutton, Andrew" To: "Ravindran, Parthasarathi" , Cullen Jennings Date: Sun, 19 Feb 2012 22:25:51 +0100 Thread-Topic: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case Thread-Index: AQHM7IE9KMJ367wTfUugOb7j2iGwS5Y/lw0AgAGhwICAA0qV0IAAPNUg Message-ID: <101C6067BEC68246B0C3F6843BCCC1E312942242CD@MCHP058A.global-ad.net> References: <7F2072F1E0DE894DA4B517B93C6A05852C3D87E060@ESESSCMS0356.eemea.ericsson.se> <3CBDF06F-F52D-4C09-A78F-1A0D8479572A@iii.ca> <7F2072F1E0DE894DA4B517B93C6A05852C3D87E58F@ESESSCMS0356.eemea.ericsson.se> <101C6067BEC68246B0C3F6843BCCC1E31202EDA663@MCHP058A.global-ad.net> <15CD1ECE-6BDD-4EE0-AA5B-EF40616578CD@iii.ca> <387F9047F55E8C42850AD6B3A7A03C6C0E040A1D@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E040A1D@inba-mail01.sonusnet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case 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, 19 Feb 2012 21:25:55 -0000 Hi, Yes absolutely I have come across a number of scenarios in the US and in Eu= rope where media is needed in the forward direction for DTMF input after re= ceiving a 18x response and before the 200OK. IF I remember correctly callin= g FEDEX was actually one of the real life examples. Regards Andy > -----Original Message----- > From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] > Sent: 19 February 2012 17:53 > To: Cullen Jennings; Hutton, Andrew > Cc: public-webrtc@w3.org; rtcweb@ietf.org > Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >=20 > Cullen, >=20 > AFAIK, 18x with sendrecv as direction attribute & DTMF (telephony- > event) is allowed by couple of operators in FEDEX (call center) > scenario. Andy will be able to double confirm whether he also comes > across the similar deployment. >=20 > Thanks > Partha >=20 >=20 >=20 > >-----Original Message----- > >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf > >Of Cullen Jennings > >Sent: Saturday, February 18, 2012 2:29 AM > >To: Hutton, Andrew > >Cc: public-webrtc@w3.org; rtcweb@ietf.org > >Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case > > > > > >On Feb 16, 2012, at 1:04 PM, Hutton, Andrew wrote: > > > >>> (Also, in the FEDEX case, there could be scenarios where the > browser > >>> does need to transit media, if the user is e.g. promted for DTMFs, > >>> voice commands etc...) > >>> > >> > >> [AndyH] - I agree that media transmission is required at this stage > so > >that the user can navigate through voice prompts (E.g. via DTMF) I > >thought this was the main requirement from the FEDEX use case. > > > >that's not my understanding. My understanding was it was one way media > >until the final response in the early media case. And the IVR sends > the > >first prompt as ringtone but cuts over before two way media (IE DTMF) > is > >needed. The whole point of this hack is to cut the time the IVR gets > >billed for but the SP is not going to provide two way media before > >billing starts. > > > > > >_______________________________________________ > >rtcweb mailing list > >rtcweb@ietf.org > >https://www.ietf.org/mailman/listinfo/rtcweb From christer.holmberg@ericsson.com Sun Feb 19 22:42: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 3D3BC21F868A for ; Sun, 19 Feb 2012 22:42:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.875 X-Spam-Level: X-Spam-Status: No, score=-9.875 tagged_above=-999 required=5 tests=[AWL=0.724, 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 ztjBBpg8O-2h for ; Sun, 19 Feb 2012 22:42:20 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE5E21F8623 for ; Sun, 19 Feb 2012 22:42:20 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-35-4f41eb4a269f Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 68.CE.27041.A4BE14F4; Mon, 20 Feb 2012 07:42:18 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Mon, 20 Feb 2012 07:42:17 +0100 From: Christer Holmberg To: "Hutton, Andrew" , "Ravindran, Parthasarathi" , Cullen Jennings Date: Mon, 20 Feb 2012 07:42:17 +0100 Thread-Topic: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case Thread-Index: AQHM7IE9KMJ367wTfUugOb7j2iGwS5Y/lw0AgAGhwICAA0qV0IAAPNUggACbz/A= Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3D8C60E1@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C3D87E060@ESESSCMS0356.eemea.ericsson.se> <3CBDF06F-F52D-4C09-A78F-1A0D8479572A@iii.ca> <7F2072F1E0DE894DA4B517B93C6A05852C3D87E58F@ESESSCMS0356.eemea.ericsson.se> <101C6067BEC68246B0C3F6843BCCC1E31202EDA663@MCHP058A.global-ad.net> <15CD1ECE-6BDD-4EE0-AA5B-EF40616578CD@iii.ca> <387F9047F55E8C42850AD6B3A7A03C6C0E040A1D@inba-mail01.sonusnet.com> <101C6067BEC68246B0C3F6843BCCC1E312942242CD@MCHP058A.global-ad.net> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E312942242CD@MCHP058A.global-ad.net> 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== Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case 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, 20 Feb 2012 06:42:21 -0000 Hi, In my opinion, even if we do need SDP_PRANSWER (Cullen may have convinced m= e that there is a need for it :), I don't think it should have an implicit = "recvonly" meaning.=20 PRANSWER or ANSWER, I think we shall use the SDP direction attribute (or so= me other explicit elements) to indicate media direction. Regards, Christer =20 -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Hutton, Andrew Sent: 19. helmikuuta 2012 23:26 To: Ravindran, Parthasarathi; Cullen Jennings Cc: rtcweb@ietf.org; public-webrtc@w3.org Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case Hi, Yes absolutely I have come across a number of scenarios in the US and in Eu= rope where media is needed in the forward direction for DTMF input after re= ceiving a 18x response and before the 200OK. IF I remember correctly callin= g FEDEX was actually one of the real life examples. Regards Andy > -----Original Message----- > From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] > Sent: 19 February 2012 17:53 > To: Cullen Jennings; Hutton, Andrew > Cc: public-webrtc@w3.org; rtcweb@ietf.org > Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >=20 > Cullen, >=20 > AFAIK, 18x with sendrecv as direction attribute & DTMF (telephony- > event) is allowed by couple of operators in FEDEX (call center)=20 > scenario. Andy will be able to double confirm whether he also comes=20 > across the similar deployment. >=20 > Thanks > Partha >=20 >=20 >=20 > >-----Original Message----- > >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf > >Of Cullen Jennings > >Sent: Saturday, February 18, 2012 2:29 AM > >To: Hutton, Andrew > >Cc: public-webrtc@w3.org; rtcweb@ietf.org > >Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case > > > > > >On Feb 16, 2012, at 1:04 PM, Hutton, Andrew wrote: > > > >>> (Also, in the FEDEX case, there could be scenarios where the > browser > >>> does need to transit media, if the user is e.g. promted for DTMFs,=20 > >>> voice commands etc...) > >>> > >> > >> [AndyH] - I agree that media transmission is required at this stage > so > >that the user can navigate through voice prompts (E.g. via DTMF) I=20 > >thought this was the main requirement from the FEDEX use case. > > > >that's not my understanding. My understanding was it was one way=20 > >media until the final response in the early media case. And the IVR=20 > >sends > the > >first prompt as ringtone but cuts over before two way media (IE DTMF) > is > >needed. The whole point of this hack is to cut the time the IVR gets=20 > >billed for but the SP is not going to provide two way media before=20 > >billing starts. > > > > > >_______________________________________________ > >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 Sun Feb 19 22:59:03 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 3C35B21F8422 for ; Sun, 19 Feb 2012 22:59:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 SRJJ8FG6cmhr for ; Sun, 19 Feb 2012 22:59:02 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id C97E021F844E for ; Sun, 19 Feb 2012 22:59:01 -0800 (PST) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q1K6xbQr017298; Mon, 20 Feb 2012 01:59:37 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 Feb 2012 01:58:49 -0500 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 Feb 2012 12:29:01 +0530 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; Mon, 20 Feb 2012 12:29:01 +0530 From: "Ravindran, Parthasarathi" To: Christer Holmberg , "Hutton, Andrew" , Cullen Jennings Thread-Topic: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case Thread-Index: AQHM7IE9KMJ367wTfUugOb7j2iGwS5Y/lw0AgAGhwICAA0qV0IAAPNUggACbz/CAAAEzEA== Date: Mon, 20 Feb 2012 06:59:00 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E040C04@inba-mail01.sonusnet.com> References: <7F2072F1E0DE894DA4B517B93C6A05852C3D87E060@ESESSCMS0356.eemea.ericsson.se> <3CBDF06F-F52D-4C09-A78F-1A0D8479572A@iii.ca> <7F2072F1E0DE894DA4B517B93C6A05852C3D87E58F@ESESSCMS0356.eemea.ericsson.se> <101C6067BEC68246B0C3F6843BCCC1E31202EDA663@MCHP058A.global-ad.net> <15CD1ECE-6BDD-4EE0-AA5B-EF40616578CD@iii.ca> <387F9047F55E8C42850AD6B3A7A03C6C0E040A1D@inba-mail01.sonusnet.com> <101C6067BEC68246B0C3F6843BCCC1E312942242CD@MCHP058A.global-ad.net> <7F2072F1E0DE894DA4B517B93C6A05852C3D8C60E1@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3D8C60E1@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.70] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 20 Feb 2012 06:59:01.0541 (UTC) FILETIME=[2029B550:01CCEF9D] Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case 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, 20 Feb 2012 06:59:03 -0000 Hi Christer, IIUC, your proposal is to update JSEP SDP_PRANSWER and SDP_ANSWER as equiva= lent to moreComing=3Dtrue/false in ROAP. Also, we need to consider the scen= ario like 18x with SDP (SDP_PRANSWER) and 2xx without SDP wherein JS has to= take care of SDP_ANSWER even though it does not receive one. IMO, Multiple= answer issue is not fully solved in ROAP as well. Also, I have the problem in the understanding the strong need for different= iating answer and final answer. Could you please clarify it. Thanks Partha=20 >-----Original Message----- >From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >Sent: Monday, February 20, 2012 12:12 PM >To: Hutton, Andrew; Ravindran, Parthasarathi; Cullen Jennings >Cc: rtcweb@ietf.org; public-webrtc@w3.org >Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case > > >Hi, > >In my opinion, even if we do need SDP_PRANSWER (Cullen may have >convinced me that there is a need for it :), I don't think it should >have an implicit "recvonly" meaning. > >PRANSWER or ANSWER, I think we shall use the SDP direction attribute (or >some other explicit elements) to indicate media direction. > >Regards, > >Christer > > > >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of Hutton, Andrew >Sent: 19. helmikuuta 2012 23:26 >To: Ravindran, Parthasarathi; Cullen Jennings >Cc: rtcweb@ietf.org; public-webrtc@w3.org >Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case > >Hi, > >Yes absolutely I have come across a number of scenarios in the US and in >Europe where media is needed in the forward direction for DTMF input >after receiving a 18x response and before the 200OK. IF I remember >correctly calling FEDEX was actually one of the real life examples. > >Regards >Andy > > >> -----Original Message----- >> From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] >> Sent: 19 February 2012 17:53 >> To: Cullen Jennings; Hutton, Andrew >> Cc: public-webrtc@w3.org; rtcweb@ietf.org >> Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >> >> Cullen, >> >> AFAIK, 18x with sendrecv as direction attribute & DTMF (telephony- >> event) is allowed by couple of operators in FEDEX (call center) >> scenario. Andy will be able to double confirm whether he also comes >> across the similar deployment. >> >> Thanks >> Partha >> >> >> >> >-----Original Message----- >> >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >> Behalf >> >Of Cullen Jennings >> >Sent: Saturday, February 18, 2012 2:29 AM >> >To: Hutton, Andrew >> >Cc: public-webrtc@w3.org; rtcweb@ietf.org >> >Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >> > >> > >> >On Feb 16, 2012, at 1:04 PM, Hutton, Andrew wrote: >> > >> >>> (Also, in the FEDEX case, there could be scenarios where the >> browser >> >>> does need to transit media, if the user is e.g. promted for DTMFs, >> >>> voice commands etc...) >> >>> >> >> >> >> [AndyH] - I agree that media transmission is required at this stage >> so >> >that the user can navigate through voice prompts (E.g. via DTMF) I >> >thought this was the main requirement from the FEDEX use case. >> > >> >that's not my understanding. My understanding was it was one way >> >media until the final response in the early media case. And the IVR >> >sends >> the >> >first prompt as ringtone but cuts over before two way media (IE DTMF) >> is >> >needed. The whole point of this hack is to cut the time the IVR gets >> >billed for but the SP is not going to provide two way media before >> >billing starts. >> > >> > >> >_______________________________________________ >> >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 christer.holmberg@ericsson.com Sun Feb 19 23:20: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 6206321F8671 for ; Sun, 19 Feb 2012 23:20:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.894 X-Spam-Level: X-Spam-Status: No, score=-9.894 tagged_above=-999 required=5 tests=[AWL=0.705, 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 nLaPKIKhk85P for ; Sun, 19 Feb 2012 23:20:41 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 8738921F86B9 for ; Sun, 19 Feb 2012 23:20:40 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-9e-4f41f4473ba9 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 71.45.27041.744F14F4; Mon, 20 Feb 2012 08:20:39 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Mon, 20 Feb 2012 08:20:39 +0100 From: Christer Holmberg To: "Ravindran, Parthasarathi" , "Hutton, Andrew" , Cullen Jennings Date: Mon, 20 Feb 2012 08:20:37 +0100 Thread-Topic: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case Thread-Index: AQHM7IE9KMJ367wTfUugOb7j2iGwS5Y/lw0AgAGhwICAA0qV0IAAPNUggACbz/CAAAEzEIAACBRA Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3D8C6134@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C3D87E060@ESESSCMS0356.eemea.ericsson.se> <3CBDF06F-F52D-4C09-A78F-1A0D8479572A@iii.ca> <7F2072F1E0DE894DA4B517B93C6A05852C3D87E58F@ESESSCMS0356.eemea.ericsson.se> <101C6067BEC68246B0C3F6843BCCC1E31202EDA663@MCHP058A.global-ad.net> <15CD1ECE-6BDD-4EE0-AA5B-EF40616578CD@iii.ca> <387F9047F55E8C42850AD6B3A7A03C6C0E040A1D@inba-mail01.sonusnet.com> <101C6067BEC68246B0C3F6843BCCC1E312942242CD@MCHP058A.global-ad.net> <7F2072F1E0DE894DA4B517B93C6A05852C3D8C60E1@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E040C04@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E040C04@inba-mail01.sonusnet.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-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case 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, 20 Feb 2012 07:20:45 -0000 Hi,=20 > IIUC, your proposal is to update JSEP SDP_PRANSWER and SDP_ANSWER as equi= valent to moreComing=3Dtrue/false in ROAP. Also, we need to consider the sc= enario like 18x with SDP (SDP_PRANSWER) and=20 > 2xx without SDP wherein JS has to take care of SDP_ANSWER even though it = does not receive one. IMO, Multiple answer issue is not fully solved in ROA= P as well. In that case, I guess the JS app could simply take a previous SDP_PRANSWER,= and send it as SDP_ANSWER. > Also, I have the problem in the understanding the strong need for differe= ntiating answer and final answer. Could you please clarify it. I had exactly the same issue, but what Cullen told me last week made me re-= think. It's all about resources :) So, take the following example: 1. The browser creates an offer, and reservers resrouces for codecs X and Y= . 2. At some point, the browser receives a PRANSWER, with only codec X. Howev= er, the browser still keeps the resources for Y, as a new answer may come. 3. At some point, the browser receives another PRANSWER (maybe forking has = occured), with only codec Y. However, the browser still keeps the resources= for X (again, as a new answer may come). 4. At some point, the browser recieves an ANSWER, with only codec X. Now, a= s this is the last answer, the browser can release the resources for Y. So, the main difference is related to the resources associated with the off= er. Once a final answer (ANSWER) has been received, and resources that were= reserved for the offer, but are no longer needed, can be released. (Cullen, please correct me if I've missunderstood :) Regards, Christer >-----Original Message----- >From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >Sent: Monday, February 20, 2012 12:12 PM >To: Hutton, Andrew; Ravindran, Parthasarathi; Cullen Jennings >Cc: rtcweb@ietf.org; public-webrtc@w3.org >Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case > > >Hi, > >In my opinion, even if we do need SDP_PRANSWER (Cullen may have=20 >convinced me that there is a need for it :), I don't think it should=20 >have an implicit "recvonly" meaning. > >PRANSWER or ANSWER, I think we shall use the SDP direction attribute=20 >(or some other explicit elements) to indicate media direction. > >Regards, > >Christer > > > >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On=20 >Behalf Of Hutton, Andrew >Sent: 19. helmikuuta 2012 23:26 >To: Ravindran, Parthasarathi; Cullen Jennings >Cc: rtcweb@ietf.org; public-webrtc@w3.org >Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case > >Hi, > >Yes absolutely I have come across a number of scenarios in the US and=20 >in Europe where media is needed in the forward direction for DTMF input=20 >after receiving a 18x response and before the 200OK. IF I remember=20 >correctly calling FEDEX was actually one of the real life examples. > >Regards >Andy > > >> -----Original Message----- >> From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] >> Sent: 19 February 2012 17:53 >> To: Cullen Jennings; Hutton, Andrew >> Cc: public-webrtc@w3.org; rtcweb@ietf.org >> Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >> >> Cullen, >> >> AFAIK, 18x with sendrecv as direction attribute & DTMF (telephony- >> event) is allowed by couple of operators in FEDEX (call center)=20 >> scenario. Andy will be able to double confirm whether he also comes=20 >> across the similar deployment. >> >> Thanks >> Partha >> >> >> >> >-----Original Message----- >> >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >> Behalf >> >Of Cullen Jennings >> >Sent: Saturday, February 18, 2012 2:29 AM >> >To: Hutton, Andrew >> >Cc: public-webrtc@w3.org; rtcweb@ietf.org >> >Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >> > >> > >> >On Feb 16, 2012, at 1:04 PM, Hutton, Andrew wrote: >> > >> >>> (Also, in the FEDEX case, there could be scenarios where the >> browser >> >>> does need to transit media, if the user is e.g. promted for=20 >> >>> DTMFs, voice commands etc...) >> >>> >> >> >> >> [AndyH] - I agree that media transmission is required at this=20 >> >> stage >> so >> >that the user can navigate through voice prompts (E.g. via DTMF) I=20 >> >thought this was the main requirement from the FEDEX use case. >> > >> >that's not my understanding. My understanding was it was one way=20 >> >media until the final response in the early media case. And the IVR=20 >> >sends >> the >> >first prompt as ringtone but cuts over before two way media (IE=20 >> >DTMF) >> is >> >needed. The whole point of this hack is to cut the time the IVR gets=20 >> >billed for but the SP is not going to provide two way media before=20 >> >billing starts. >> > >> > >> >_______________________________________________ >> >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 ibc@aliax.net Mon Feb 20 00:55:08 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 1F3AD21F8533 for ; Mon, 20 Feb 2012 00:55:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.613 X-Spam-Level: X-Spam-Status: No, score=-2.613 tagged_above=-999 required=5 tests=[AWL=0.064, 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 8bXshVtLF7dK for ; Mon, 20 Feb 2012 00:55:07 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id D4E6921F86E3 for ; Mon, 20 Feb 2012 00:55:03 -0800 (PST) Received: by vcbfk14 with SMTP id fk14so3959202vcb.31 for ; Mon, 20 Feb 2012 00:55:03 -0800 (PST) Received-SPF: pass (google.com: domain of ibc@aliax.net designates 10.220.156.201 as permitted sender) client-ip=10.220.156.201; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ibc@aliax.net designates 10.220.156.201 as permitted sender) smtp.mail=ibc@aliax.net Received: from mr.google.com ([10.220.156.201]) by 10.220.156.201 with SMTP id y9mr5240544vcw.22.1329728103414 (num_hops = 1); Mon, 20 Feb 2012 00:55:03 -0800 (PST) Received: by 10.220.156.201 with SMTP id y9mr4103452vcw.22.1329728103259; Mon, 20 Feb 2012 00:55:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.203.2 with HTTP; Mon, 20 Feb 2012 00:54:43 -0800 (PST) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3D8C6134@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C3D87E060@ESESSCMS0356.eemea.ericsson.se> <3CBDF06F-F52D-4C09-A78F-1A0D8479572A@iii.ca> <7F2072F1E0DE894DA4B517B93C6A05852C3D87E58F@ESESSCMS0356.eemea.ericsson.se> <101C6067BEC68246B0C3F6843BCCC1E31202EDA663@MCHP058A.global-ad.net> <15CD1ECE-6BDD-4EE0-AA5B-EF40616578CD@iii.ca> <387F9047F55E8C42850AD6B3A7A03C6C0E040A1D@inba-mail01.sonusnet.com> <101C6067BEC68246B0C3F6843BCCC1E312942242CD@MCHP058A.global-ad.net> <7F2072F1E0DE894DA4B517B93C6A05852C3D8C60E1@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E040C04@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C3D8C6134@ESESSCMS0356.eemea.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 20 Feb 2012 09:54:43 +0100 Message-ID: To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQngxkFRXlNwqVsEGyWw+JEtAA8RG3T+rnbpYeA2zLtcCUS0LvE7h49Mk8wvjre2cPNBeacy Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case 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, 20 Feb 2012 08:55:08 -0000 2012/2/20 Christer Holmberg : >> IIUC, your proposal is to update JSEP SDP_PRANSWER and SDP_ANSWER as equ= ivalent to moreComing=3Dtrue/false in ROAP. Also, we need to consider the s= cenario like 18x with SDP (SDP_PRANSWER) and >> 2xx without SDP wherein JS has to take care of SDP_ANSWER even though it= does not receive one. IMO, Multiple answer issue is not fully solved in RO= AP as well. > > In that case, I guess the JS app could simply take a previous SDP_PRANSWE= R, and send it as SDP_ANSWER. Right, and that is just custom JavaScript stuff just depending on the chosen on-the-wire signaing mechanism. WebRTC should not be aware about SIP semantics. If someone implements SIP or something "like SIP" in JavaScript and wants to deal with an empty 200 OK after a 180/183 with SDP, then he should handle it in his custom JavaScript code. WebRTC is out of that scope. --=20 I=C3=B1aki Baz Castillo From pravindran@sonusnet.com Mon Feb 20 01: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 2861221F870E for ; Mon, 20 Feb 2012 01:55:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 GtAj16Mt700H for ; Mon, 20 Feb 2012 01:55:01 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id C0EC121F86F0 for ; Mon, 20 Feb 2012 01:55:00 -0800 (PST) Received: from sonusmail06.sonusnet.com (sonusmail06.sonusnet.com [10.128.32.156]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q1K9tjRU001723; Mon, 20 Feb 2012 04:55:45 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail06.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 Feb 2012 04:54:56 -0500 Received: from INBA-HUB02.sonusnet.com ([10.70.51.87]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 Feb 2012 15:25:08 +0530 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, 20 Feb 2012 15:25:08 +0530 From: "Ravindran, Parthasarathi" To: Christer Holmberg , "Hutton, Andrew" , Cullen Jennings Thread-Topic: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case Thread-Index: AQHM7IE9KMJ367wTfUugOb7j2iGwS5Y/lw0AgAGhwICAA0qV0IAAPNUggACbz/CAAAEzEIAACBRAgAASIBA= Date: Mon, 20 Feb 2012 09:55:07 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E040C6D@inba-mail01.sonusnet.com> References: <7F2072F1E0DE894DA4B517B93C6A05852C3D87E060@ESESSCMS0356.eemea.ericsson.se> <3CBDF06F-F52D-4C09-A78F-1A0D8479572A@iii.ca> <7F2072F1E0DE894DA4B517B93C6A05852C3D87E58F@ESESSCMS0356.eemea.ericsson.se> <101C6067BEC68246B0C3F6843BCCC1E31202EDA663@MCHP058A.global-ad.net> <15CD1ECE-6BDD-4EE0-AA5B-EF40616578CD@iii.ca> <387F9047F55E8C42850AD6B3A7A03C6C0E040A1D@inba-mail01.sonusnet.com> <101C6067BEC68246B0C3F6843BCCC1E312942242CD@MCHP058A.global-ad.net> <7F2072F1E0DE894DA4B517B93C6A05852C3D8C60E1@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E040C04@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C3D8C6134@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3D8C6134@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.70] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 20 Feb 2012 09:55:08.0983 (UTC) FILETIME=[BAD96470:01CCEFB5] Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case 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, 20 Feb 2012 09:55:05 -0000 Hi Christer, Even I had thought through Cullen statement before reply to him in the anot= her mail thread. As per your clarification, Each Codec (like g711 library, = g729 library) will be loaded in the memory in the run-time based on offer a= nd released based on the final answer for the memory saving. I agree that t= his mechanism is useful for DSP based VoIP endpoints wherein it is possible= to load only one codec (or few codec) at the same time, mostly only one of= the codec (first codec) will be loaded based on the answer and send Re-INV= ITE to indicate the committed codec in DSP. My understanding is that the sa= me issue does not exists for WebRTC browser running in laptop, desktop and = those devices will be capable of loading the multiple codec without impacti= ng the system performance. Please correct me in case I misunderstand the sy= stem design here. I'm not very sure about Smartphone architecture w.r.t mul= tiple codec handling. =20 I have asked for 18x with SDP and 2xx without SDP scenario just to indicate= the complication building up in the JavaScript offer/answer FSM because of= the (provisional/final) response specific offer/answer model.=20 Thanks Partha >-----Original Message----- >From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >Sent: Monday, February 20, 2012 12:51 PM >To: Ravindran, Parthasarathi; Hutton, Andrew; Cullen Jennings >Cc: rtcweb@ietf.org; public-webrtc@w3.org >Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case > > >Hi, > >> IIUC, your proposal is to update JSEP SDP_PRANSWER and SDP_ANSWER as >> equivalent to moreComing=3Dtrue/false in ROAP. Also, we need to consider >the scenario like 18x with SDP (SDP_PRANSWER) and 2xx without SDP >wherein JS has to take care of SDP_ANSWER even though it does not >receive one. IMO, Multiple answer issue is not fully solved in ROAP as >well. > >In that case, I guess the JS app could simply take a previous >SDP_PRANSWER, and send it as SDP_ANSWER. > >> Also, I have the problem in the understanding the strong need for >differentiating answer and final answer. Could you please clarify it. > >I had exactly the same issue, but what Cullen told me last week made me >re-think. It's all about resources :) > >So, take the following example: > >1. The browser creates an offer, and reservers resrouces for codecs X >and Y. >2. At some point, the browser receives a PRANSWER, with only codec X. >However, the browser still keeps the resources for Y, as a new answer >may come. >3. At some point, the browser receives another PRANSWER (maybe forking >has occured), with only codec Y. However, the browser still keeps the >resources for X (again, as a new answer may come). >4. At some point, the browser recieves an ANSWER, with only codec X. >Now, as this is the last answer, the browser can release the resources >for Y. > >So, the main difference is related to the resources associated with the >offer. Once a final answer (ANSWER) has been received, and resources >that were reserved for the offer, but are no longer needed, can be >released. > >(Cullen, please correct me if I've missunderstood :) > >Regards, > >Christer > > >>-----Original Message----- >>From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>Sent: Monday, February 20, 2012 12:12 PM >>To: Hutton, Andrew; Ravindran, Parthasarathi; Cullen Jennings >>Cc: rtcweb@ietf.org; public-webrtc@w3.org >>Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >> >> >>Hi, >> >>In my opinion, even if we do need SDP_PRANSWER (Cullen may have >>convinced me that there is a need for it :), I don't think it should >>have an implicit "recvonly" meaning. >> >>PRANSWER or ANSWER, I think we shall use the SDP direction attribute >>(or some other explicit elements) to indicate media direction. >> >>Regards, >> >>Christer >> >> >> >>-----Original Message----- >>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >>Behalf Of Hutton, Andrew >>Sent: 19. helmikuuta 2012 23:26 >>To: Ravindran, Parthasarathi; Cullen Jennings >>Cc: rtcweb@ietf.org; public-webrtc@w3.org >>Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >> >>Hi, >> >>Yes absolutely I have come across a number of scenarios in the US and >>in Europe where media is needed in the forward direction for DTMF input >>after receiving a 18x response and before the 200OK. IF I remember >>correctly calling FEDEX was actually one of the real life examples. >> >>Regards >>Andy >> >> >>> -----Original Message----- >>> From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] >>> Sent: 19 February 2012 17:53 >>> To: Cullen Jennings; Hutton, Andrew >>> Cc: public-webrtc@w3.org; rtcweb@ietf.org >>> Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >>> >>> Cullen, >>> >>> AFAIK, 18x with sendrecv as direction attribute & DTMF (telephony- >>> event) is allowed by couple of operators in FEDEX (call center) >>> scenario. Andy will be able to double confirm whether he also comes >>> across the similar deployment. >>> >>> Thanks >>> Partha >>> >>> >>> >>> >-----Original Message----- >>> >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >>> Behalf >>> >Of Cullen Jennings >>> >Sent: Saturday, February 18, 2012 2:29 AM >>> >To: Hutton, Andrew >>> >Cc: public-webrtc@w3.org; rtcweb@ietf.org >>> >Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >>> > >>> > >>> >On Feb 16, 2012, at 1:04 PM, Hutton, Andrew wrote: >>> > >>> >>> (Also, in the FEDEX case, there could be scenarios where the >>> browser >>> >>> does need to transit media, if the user is e.g. promted for >>> >>> DTMFs, voice commands etc...) >>> >>> >>> >> >>> >> [AndyH] - I agree that media transmission is required at this >>> >> stage >>> so >>> >that the user can navigate through voice prompts (E.g. via DTMF) I >>> >thought this was the main requirement from the FEDEX use case. >>> > >>> >that's not my understanding. My understanding was it was one way >>> >media until the final response in the early media case. And the IVR >>> >sends >>> the >>> >first prompt as ringtone but cuts over before two way media (IE >>> >DTMF) >>> is >>> >needed. The whole point of this hack is to cut the time the IVR gets >>> >billed for but the SP is not going to provide two way media before >>> >billing starts. >>> > >>> > >>> >_______________________________________________ >>> >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 christer.holmberg@ericsson.com Mon Feb 20 02:08: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 C80DF21F8456 for ; Mon, 20 Feb 2012 02:08:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.912 X-Spam-Level: X-Spam-Status: No, score=-9.912 tagged_above=-999 required=5 tests=[AWL=0.687, 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 RuwK7blTV5GE for ; Mon, 20 Feb 2012 02:08:46 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 7820621F8739 for ; Mon, 20 Feb 2012 02:08:42 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-00-4f421ba9b79d Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 92.C9.01970.9AB124F4; Mon, 20 Feb 2012 11:08:41 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Mon, 20 Feb 2012 11:08:38 +0100 From: Christer Holmberg To: "Ravindran, Parthasarathi" , "Hutton, Andrew" , Cullen Jennings Date: Mon, 20 Feb 2012 11:08:37 +0100 Thread-Topic: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case Thread-Index: AQHM7IE9KMJ367wTfUugOb7j2iGwS5Y/lw0AgAGhwICAA0qV0IAAPNUggACbz/CAAAEzEIAACBRAgAASIBCAAB2GgA== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3D8C630B@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C3D87E060@ESESSCMS0356.eemea.ericsson.se> <3CBDF06F-F52D-4C09-A78F-1A0D8479572A@iii.ca> <7F2072F1E0DE894DA4B517B93C6A05852C3D87E58F@ESESSCMS0356.eemea.ericsson.se> <101C6067BEC68246B0C3F6843BCCC1E31202EDA663@MCHP058A.global-ad.net> <15CD1ECE-6BDD-4EE0-AA5B-EF40616578CD@iii.ca> <387F9047F55E8C42850AD6B3A7A03C6C0E040A1D@inba-mail01.sonusnet.com> <101C6067BEC68246B0C3F6843BCCC1E312942242CD@MCHP058A.global-ad.net> <7F2072F1E0DE894DA4B517B93C6A05852C3D8C60E1@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E040C04@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C3D8C6134@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E040C6D@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E040C6D@inba-mail01.sonusnet.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-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case 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, 20 Feb 2012 10:08:48 -0000 Hi, Mobile devices (smartphones etc) will often have limited resources, no matt= er whether the app is running as a browser app or a native app. Also, codec was only one example. A better example is perhaps resources rel= ated to ICE, media security etc. Regards, Christer -----Original Message----- From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com]=20 Sent: 20. helmikuuta 2012 11:55 To: Christer Holmberg; Hutton, Andrew; Cullen Jennings Cc: rtcweb@ietf.org; public-webrtc@w3.org Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case Hi Christer, Even I had thought through Cullen statement before reply to him in the anot= her mail thread. As per your clarification, Each Codec (like g711 library, = g729 library) will be loaded in the memory in the run-time based on offer a= nd released based on the final answer for the memory saving. I agree that t= his mechanism is useful for DSP based VoIP endpoints wherein it is possible= to load only one codec (or few codec) at the same time, mostly only one of= the codec (first codec) will be loaded based on the answer and send Re-INV= ITE to indicate the committed codec in DSP. My understanding is that the sa= me issue does not exists for WebRTC browser running in laptop, desktop and = those devices will be capable of loading the multiple codec without impacti= ng the system performance. Please correct me in case I misunderstand the sy= stem design here. I'm not very sure about Smartphone architecture w.r.t mul= tiple codec handling. =20 I have asked for 18x with SDP and 2xx without SDP scenario just to indicate= the complication building up in the JavaScript offer/answer FSM because of= the (provisional/final) response specific offer/answer model.=20 Thanks Partha >-----Original Message----- >From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >Sent: Monday, February 20, 2012 12:51 PM >To: Ravindran, Parthasarathi; Hutton, Andrew; Cullen Jennings >Cc: rtcweb@ietf.org; public-webrtc@w3.org >Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case > > >Hi, > >> IIUC, your proposal is to update JSEP SDP_PRANSWER and SDP_ANSWER as=20 >> equivalent to moreComing=3Dtrue/false in ROAP. Also, we need to=20 >> consider >the scenario like 18x with SDP (SDP_PRANSWER) and 2xx without SDP=20 >wherein JS has to take care of SDP_ANSWER even though it does not=20 >receive one. IMO, Multiple answer issue is not fully solved in ROAP as=20 >well. > >In that case, I guess the JS app could simply take a previous=20 >SDP_PRANSWER, and send it as SDP_ANSWER. > >> Also, I have the problem in the understanding the strong need for >differentiating answer and final answer. Could you please clarify it. > >I had exactly the same issue, but what Cullen told me last week made me=20 >re-think. It's all about resources :) > >So, take the following example: > >1. The browser creates an offer, and reservers resrouces for codecs X=20 >and Y. >2. At some point, the browser receives a PRANSWER, with only codec X. >However, the browser still keeps the resources for Y, as a new answer=20 >may come. >3. At some point, the browser receives another PRANSWER (maybe forking=20 >has occured), with only codec Y. However, the browser still keeps the=20 >resources for X (again, as a new answer may come). >4. At some point, the browser recieves an ANSWER, with only codec X. >Now, as this is the last answer, the browser can release the resources=20 >for Y. > >So, the main difference is related to the resources associated with the=20 >offer. Once a final answer (ANSWER) has been received, and resources=20 >that were reserved for the offer, but are no longer needed, can be=20 >released. > >(Cullen, please correct me if I've missunderstood :) > >Regards, > >Christer > > >>-----Original Message----- >>From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>Sent: Monday, February 20, 2012 12:12 PM >>To: Hutton, Andrew; Ravindran, Parthasarathi; Cullen Jennings >>Cc: rtcweb@ietf.org; public-webrtc@w3.org >>Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >> >> >>Hi, >> >>In my opinion, even if we do need SDP_PRANSWER (Cullen may have=20 >>convinced me that there is a need for it :), I don't think it should=20 >>have an implicit "recvonly" meaning. >> >>PRANSWER or ANSWER, I think we shall use the SDP direction attribute=20 >>(or some other explicit elements) to indicate media direction. >> >>Regards, >> >>Christer >> >> >> >>-----Original Message----- >>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On=20 >>Behalf Of Hutton, Andrew >>Sent: 19. helmikuuta 2012 23:26 >>To: Ravindran, Parthasarathi; Cullen Jennings >>Cc: rtcweb@ietf.org; public-webrtc@w3.org >>Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >> >>Hi, >> >>Yes absolutely I have come across a number of scenarios in the US and=20 >>in Europe where media is needed in the forward direction for DTMF=20 >>input after receiving a 18x response and before the 200OK. IF I=20 >>remember correctly calling FEDEX was actually one of the real life exampl= es. >> >>Regards >>Andy >> >> >>> -----Original Message----- >>> From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] >>> Sent: 19 February 2012 17:53 >>> To: Cullen Jennings; Hutton, Andrew >>> Cc: public-webrtc@w3.org; rtcweb@ietf.org >>> Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >>> >>> Cullen, >>> >>> AFAIK, 18x with sendrecv as direction attribute & DTMF (telephony- >>> event) is allowed by couple of operators in FEDEX (call center)=20 >>> scenario. Andy will be able to double confirm whether he also comes=20 >>> across the similar deployment. >>> >>> Thanks >>> Partha >>> >>> >>> >>> >-----Original Message----- >>> >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >>> Behalf >>> >Of Cullen Jennings >>> >Sent: Saturday, February 18, 2012 2:29 AM >>> >To: Hutton, Andrew >>> >Cc: public-webrtc@w3.org; rtcweb@ietf.org >>> >Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >>> > >>> > >>> >On Feb 16, 2012, at 1:04 PM, Hutton, Andrew wrote: >>> > >>> >>> (Also, in the FEDEX case, there could be scenarios where the >>> browser >>> >>> does need to transit media, if the user is e.g. promted for=20 >>> >>> DTMFs, voice commands etc...) >>> >>> >>> >> >>> >> [AndyH] - I agree that media transmission is required at this=20 >>> >> stage >>> so >>> >that the user can navigate through voice prompts (E.g. via DTMF) I=20 >>> >thought this was the main requirement from the FEDEX use case. >>> > >>> >that's not my understanding. My understanding was it was one way=20 >>> >media until the final response in the early media case. And the IVR=20 >>> >sends >>> the >>> >first prompt as ringtone but cuts over before two way media (IE >>> >DTMF) >>> is >>> >needed. The whole point of this hack is to cut the time the IVR=20 >>> >gets billed for but the SP is not going to provide two way media=20 >>> >before billing starts. >>> > >>> > >>> >_______________________________________________ >>> >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 Mon Feb 20 02:40: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 977F321F875A for ; Mon, 20 Feb 2012 02:40:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 SQiAUf4GJ-Lz for ; Mon, 20 Feb 2012 02:40:55 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 0901721F8757 for ; Mon, 20 Feb 2012 02:40:54 -0800 (PST) Received: from sonusmail07.sonusnet.com (sonusmail07.sonusnet.com [10.128.32.157]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q1KAfdtW031979; Mon, 20 Feb 2012 05:41:39 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 Feb 2012 05:40:50 -0500 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 Feb 2012 16:11:03 +0530 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; Mon, 20 Feb 2012 16:11:02 +0530 From: "Ravindran, Parthasarathi" To: Christer Holmberg , "Hutton, Andrew" , Cullen Jennings Thread-Topic: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case Thread-Index: AQHM7IE9KMJ367wTfUugOb7j2iGwS5Y/lw0AgAGhwICAA0qV0IAAPNUggACbz/CAAAEzEIAACBRAgAASIBCAAB2GgIAABh6A Date: Mon, 20 Feb 2012 10:41:01 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E040CBF@inba-mail01.sonusnet.com> References: <7F2072F1E0DE894DA4B517B93C6A05852C3D87E060@ESESSCMS0356.eemea.ericsson.se> <3CBDF06F-F52D-4C09-A78F-1A0D8479572A@iii.ca> <7F2072F1E0DE894DA4B517B93C6A05852C3D87E58F@ESESSCMS0356.eemea.ericsson.se> <101C6067BEC68246B0C3F6843BCCC1E31202EDA663@MCHP058A.global-ad.net> <15CD1ECE-6BDD-4EE0-AA5B-EF40616578CD@iii.ca> <387F9047F55E8C42850AD6B3A7A03C6C0E040A1D@inba-mail01.sonusnet.com> <101C6067BEC68246B0C3F6843BCCC1E312942242CD@MCHP058A.global-ad.net> <7F2072F1E0DE894DA4B517B93C6A05852C3D8C60E1@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E040C04@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C3D8C6134@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E040C6D@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C3D8C630B@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3D8C630B@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.70] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 20 Feb 2012 10:41:03.0423 (UTC) FILETIME=[249F94F0:01CCEFBC] Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case 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, 20 Feb 2012 10:40:59 -0000 Hi Christer, It is obvious fact that mobile devices has limited resource. The question i= s whether Mobile devices offer multiple codec during the initial offer and = waiting to release during the final answer for saving memory resource. Fina= l answer expecting design may have the impact because the badly designed we= bpage may hog the system easily by just sending offer & not mapping with an= swer and also in the scenario of answerer reply with multiple codec.=20 As part of SRTP discussion, Eric clarifies that Media security (SRTP) is no= t an (CPU) performance issue in the endpoint. I could not understand about = ICE issues as ICE is triggered based on the number of answer apart from the= initial ICE procedure for offer.=20 Thanks Partha >-----Original Message----- >From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >Sent: Monday, February 20, 2012 3:39 PM >To: Ravindran, Parthasarathi; Hutton, Andrew; Cullen Jennings >Cc: rtcweb@ietf.org; public-webrtc@w3.org >Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case > > >Hi, > >Mobile devices (smartphones etc) will often have limited resources, no >matter whether the app is running as a browser app or a native app. > >Also, codec was only one example. A better example is perhaps resources >related to ICE, media security etc. > >Regards, > >Christer > > >-----Original Message----- >From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] >Sent: 20. helmikuuta 2012 11:55 >To: Christer Holmberg; Hutton, Andrew; Cullen Jennings >Cc: rtcweb@ietf.org; public-webrtc@w3.org >Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case > >Hi Christer, > >Even I had thought through Cullen statement before reply to him in the >another mail thread. As per your clarification, Each Codec (like g711 >library, g729 library) will be loaded in the memory in the run-time >based on offer and released based on the final answer for the memory >saving. I agree that this mechanism is useful for DSP based VoIP >endpoints wherein it is possible to load only one codec (or few codec) >at the same time, mostly only one of the codec (first codec) will be >loaded based on the answer and send Re-INVITE to indicate the committed >codec in DSP. My understanding is that the same issue does not exists >for WebRTC browser running in laptop, desktop and those devices will be >capable of loading the multiple codec without impacting the system >performance. Please correct me in case I misunderstand the system design >here. I'm not very sure about Smartphone architecture w.r.t multiple >codec handling. > >I have asked for 18x with SDP and 2xx without SDP scenario just to >indicate the complication building up in the JavaScript offer/answer FSM >because of the (provisional/final) response specific offer/answer model. > >Thanks >Partha > >>-----Original Message----- >>From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>Sent: Monday, February 20, 2012 12:51 PM >>To: Ravindran, Parthasarathi; Hutton, Andrew; Cullen Jennings >>Cc: rtcweb@ietf.org; public-webrtc@w3.org >>Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >> >> >>Hi, >> >>> IIUC, your proposal is to update JSEP SDP_PRANSWER and SDP_ANSWER as >>> equivalent to moreComing=3Dtrue/false in ROAP. Also, we need to >>> consider >>the scenario like 18x with SDP (SDP_PRANSWER) and 2xx without SDP >>wherein JS has to take care of SDP_ANSWER even though it does not >>receive one. IMO, Multiple answer issue is not fully solved in ROAP as >>well. >> >>In that case, I guess the JS app could simply take a previous >>SDP_PRANSWER, and send it as SDP_ANSWER. >> >>> Also, I have the problem in the understanding the strong need for >>differentiating answer and final answer. Could you please clarify it. >> >>I had exactly the same issue, but what Cullen told me last week made me >>re-think. It's all about resources :) >> >>So, take the following example: >> >>1. The browser creates an offer, and reservers resrouces for codecs X >>and Y. >>2. At some point, the browser receives a PRANSWER, with only codec X. >>However, the browser still keeps the resources for Y, as a new answer >>may come. >>3. At some point, the browser receives another PRANSWER (maybe forking >>has occured), with only codec Y. However, the browser still keeps the >>resources for X (again, as a new answer may come). >>4. At some point, the browser recieves an ANSWER, with only codec X. >>Now, as this is the last answer, the browser can release the resources >>for Y. >> >>So, the main difference is related to the resources associated with the >>offer. Once a final answer (ANSWER) has been received, and resources >>that were reserved for the offer, but are no longer needed, can be >>released. >> >>(Cullen, please correct me if I've missunderstood :) >> >>Regards, >> >>Christer >> >> >>>-----Original Message----- >>>From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>>Sent: Monday, February 20, 2012 12:12 PM >>>To: Hutton, Andrew; Ravindran, Parthasarathi; Cullen Jennings >>>Cc: rtcweb@ietf.org; public-webrtc@w3.org >>>Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >>> >>> >>>Hi, >>> >>>In my opinion, even if we do need SDP_PRANSWER (Cullen may have >>>convinced me that there is a need for it :), I don't think it should >>>have an implicit "recvonly" meaning. >>> >>>PRANSWER or ANSWER, I think we shall use the SDP direction attribute >>>(or some other explicit elements) to indicate media direction. >>> >>>Regards, >>> >>>Christer >>> >>> >>> >>>-----Original Message----- >>>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >>>Behalf Of Hutton, Andrew >>>Sent: 19. helmikuuta 2012 23:26 >>>To: Ravindran, Parthasarathi; Cullen Jennings >>>Cc: rtcweb@ietf.org; public-webrtc@w3.org >>>Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >>> >>>Hi, >>> >>>Yes absolutely I have come across a number of scenarios in the US and >>>in Europe where media is needed in the forward direction for DTMF >>>input after receiving a 18x response and before the 200OK. IF I >>>remember correctly calling FEDEX was actually one of the real life >examples. >>> >>>Regards >>>Andy >>> >>> >>>> -----Original Message----- >>>> From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] >>>> Sent: 19 February 2012 17:53 >>>> To: Cullen Jennings; Hutton, Andrew >>>> Cc: public-webrtc@w3.org; rtcweb@ietf.org >>>> Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >>>> >>>> Cullen, >>>> >>>> AFAIK, 18x with sendrecv as direction attribute & DTMF (telephony- >>>> event) is allowed by couple of operators in FEDEX (call center) >>>> scenario. Andy will be able to double confirm whether he also comes >>>> across the similar deployment. >>>> >>>> Thanks >>>> Partha >>>> >>>> >>>> >>>> >-----Original Message----- >>>> >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >>>> Behalf >>>> >Of Cullen Jennings >>>> >Sent: Saturday, February 18, 2012 2:29 AM >>>> >To: Hutton, Andrew >>>> >Cc: public-webrtc@w3.org; rtcweb@ietf.org >>>> >Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >>>> > >>>> > >>>> >On Feb 16, 2012, at 1:04 PM, Hutton, Andrew wrote: >>>> > >>>> >>> (Also, in the FEDEX case, there could be scenarios where the >>>> browser >>>> >>> does need to transit media, if the user is e.g. promted for >>>> >>> DTMFs, voice commands etc...) >>>> >>> >>>> >> >>>> >> [AndyH] - I agree that media transmission is required at this >>>> >> stage >>>> so >>>> >that the user can navigate through voice prompts (E.g. via DTMF) I >>>> >thought this was the main requirement from the FEDEX use case. >>>> > >>>> >that's not my understanding. My understanding was it was one way >>>> >media until the final response in the early media case. And the IVR >>>> >sends >>>> the >>>> >first prompt as ringtone but cuts over before two way media (IE >>>> >DTMF) >>>> is >>>> >needed. The whole point of this hack is to cut the time the IVR >>>> >gets billed for but the SP is not going to provide two way media >>>> >before billing starts. >>>> > >>>> > >>>> >_______________________________________________ >>>> >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 christer.holmberg@ericsson.com Mon Feb 20 03:16: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 87C2821F8753 for ; Mon, 20 Feb 2012 03:16:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.929 X-Spam-Level: X-Spam-Status: No, score=-9.929 tagged_above=-999 required=5 tests=[AWL=0.670, 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 oT9DPJ+anxQ7 for ; Mon, 20 Feb 2012 03:15:58 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 05C1821F8720 for ; Mon, 20 Feb 2012 03:15:57 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-46-4f422b6b6d37 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id C1.BE.27041.B6B224F4; Mon, 20 Feb 2012 12:15:55 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Mon, 20 Feb 2012 12:15:55 +0100 From: Christer Holmberg To: "Ravindran, Parthasarathi" , "Hutton, Andrew" , Cullen Jennings Date: Mon, 20 Feb 2012 12:15:54 +0100 Thread-Topic: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case Thread-Index: AQHM7IE9KMJ367wTfUugOb7j2iGwS5Y/lw0AgAGhwICAA0qV0IAAPNUggACbz/CAAAEzEIAACBRAgAASIBCAAB2GgIAABh6AgAANu/A= Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3D914C49@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C3D87E060@ESESSCMS0356.eemea.ericsson.se> <3CBDF06F-F52D-4C09-A78F-1A0D8479572A@iii.ca> <7F2072F1E0DE894DA4B517B93C6A05852C3D87E58F@ESESSCMS0356.eemea.ericsson.se> <101C6067BEC68246B0C3F6843BCCC1E31202EDA663@MCHP058A.global-ad.net> <15CD1ECE-6BDD-4EE0-AA5B-EF40616578CD@iii.ca> <387F9047F55E8C42850AD6B3A7A03C6C0E040A1D@inba-mail01.sonusnet.com> <101C6067BEC68246B0C3F6843BCCC1E312942242CD@MCHP058A.global-ad.net> <7F2072F1E0DE894DA4B517B93C6A05852C3D8C60E1@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E040C04@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C3D8C6134@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E040C6D@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C3D8C630B@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E040CBF@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E040CBF@inba-mail01.sonusnet.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-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case 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, 20 Feb 2012 11:16:04 -0000 Hi, There could always be a mechanism, where the broswer automatically releases= resources, if it hasn't received a SDP_ANSWER within a given time. Regards, Christer =20 -----Original Message----- From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com]=20 Sent: 20. helmikuuta 2012 12:41 To: Christer Holmberg; Hutton, Andrew; Cullen Jennings Cc: rtcweb@ietf.org; public-webrtc@w3.org Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case Hi Christer, It is obvious fact that mobile devices has limited resource. The question i= s whether Mobile devices offer multiple codec during the initial offer and = waiting to release during the final answer for saving memory resource. Fina= l answer expecting design may have the impact because the badly designed we= bpage may hog the system easily by just sending offer & not mapping with an= swer and also in the scenario of answerer reply with multiple codec.=20 As part of SRTP discussion, Eric clarifies that Media security (SRTP) is no= t an (CPU) performance issue in the endpoint. I could not understand about = ICE issues as ICE is triggered based on the number of answer apart from the= initial ICE procedure for offer.=20 Thanks Partha >-----Original Message----- >From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >Sent: Monday, February 20, 2012 3:39 PM >To: Ravindran, Parthasarathi; Hutton, Andrew; Cullen Jennings >Cc: rtcweb@ietf.org; public-webrtc@w3.org >Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case > > >Hi, > >Mobile devices (smartphones etc) will often have limited resources, no=20 >matter whether the app is running as a browser app or a native app. > >Also, codec was only one example. A better example is perhaps resources=20 >related to ICE, media security etc. > >Regards, > >Christer > > >-----Original Message----- >From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] >Sent: 20. helmikuuta 2012 11:55 >To: Christer Holmberg; Hutton, Andrew; Cullen Jennings >Cc: rtcweb@ietf.org; public-webrtc@w3.org >Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case > >Hi Christer, > >Even I had thought through Cullen statement before reply to him in the=20 >another mail thread. As per your clarification, Each Codec (like g711=20 >library, g729 library) will be loaded in the memory in the run-time=20 >based on offer and released based on the final answer for the memory=20 >saving. I agree that this mechanism is useful for DSP based VoIP=20 >endpoints wherein it is possible to load only one codec (or few codec)=20 >at the same time, mostly only one of the codec (first codec) will be=20 >loaded based on the answer and send Re-INVITE to indicate the committed=20 >codec in DSP. My understanding is that the same issue does not exists=20 >for WebRTC browser running in laptop, desktop and those devices will be=20 >capable of loading the multiple codec without impacting the system=20 >performance. Please correct me in case I misunderstand the system=20 >design here. I'm not very sure about Smartphone architecture w.r.t=20 >multiple codec handling. > >I have asked for 18x with SDP and 2xx without SDP scenario just to=20 >indicate the complication building up in the JavaScript offer/answer=20 >FSM because of the (provisional/final) response specific offer/answer mode= l. > >Thanks >Partha > >>-----Original Message----- >>From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>Sent: Monday, February 20, 2012 12:51 PM >>To: Ravindran, Parthasarathi; Hutton, Andrew; Cullen Jennings >>Cc: rtcweb@ietf.org; public-webrtc@w3.org >>Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >> >> >>Hi, >> >>> IIUC, your proposal is to update JSEP SDP_PRANSWER and SDP_ANSWER as=20 >>> equivalent to moreComing=3Dtrue/false in ROAP. Also, we need to=20 >>> consider >>the scenario like 18x with SDP (SDP_PRANSWER) and 2xx without SDP=20 >>wherein JS has to take care of SDP_ANSWER even though it does not=20 >>receive one. IMO, Multiple answer issue is not fully solved in ROAP as=20 >>well. >> >>In that case, I guess the JS app could simply take a previous=20 >>SDP_PRANSWER, and send it as SDP_ANSWER. >> >>> Also, I have the problem in the understanding the strong need for >>differentiating answer and final answer. Could you please clarify it. >> >>I had exactly the same issue, but what Cullen told me last week made=20 >>me re-think. It's all about resources :) >> >>So, take the following example: >> >>1. The browser creates an offer, and reservers resrouces for codecs X=20 >>and Y. >>2. At some point, the browser receives a PRANSWER, with only codec X. >>However, the browser still keeps the resources for Y, as a new answer=20 >>may come. >>3. At some point, the browser receives another PRANSWER (maybe forking=20 >>has occured), with only codec Y. However, the browser still keeps the=20 >>resources for X (again, as a new answer may come). >>4. At some point, the browser recieves an ANSWER, with only codec X. >>Now, as this is the last answer, the browser can release the resources=20 >>for Y. >> >>So, the main difference is related to the resources associated with=20 >>the offer. Once a final answer (ANSWER) has been received, and=20 >>resources that were reserved for the offer, but are no longer needed,=20 >>can be released. >> >>(Cullen, please correct me if I've missunderstood :) >> >>Regards, >> >>Christer >> >> >>>-----Original Message----- >>>From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>>Sent: Monday, February 20, 2012 12:12 PM >>>To: Hutton, Andrew; Ravindran, Parthasarathi; Cullen Jennings >>>Cc: rtcweb@ietf.org; public-webrtc@w3.org >>>Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >>> >>> >>>Hi, >>> >>>In my opinion, even if we do need SDP_PRANSWER (Cullen may have=20 >>>convinced me that there is a need for it :), I don't think it should=20 >>>have an implicit "recvonly" meaning. >>> >>>PRANSWER or ANSWER, I think we shall use the SDP direction attribute=20 >>>(or some other explicit elements) to indicate media direction. >>> >>>Regards, >>> >>>Christer >>> >>> >>> >>>-----Original Message----- >>>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On=20 >>>Behalf Of Hutton, Andrew >>>Sent: 19. helmikuuta 2012 23:26 >>>To: Ravindran, Parthasarathi; Cullen Jennings >>>Cc: rtcweb@ietf.org; public-webrtc@w3.org >>>Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >>> >>>Hi, >>> >>>Yes absolutely I have come across a number of scenarios in the US and=20 >>>in Europe where media is needed in the forward direction for DTMF=20 >>>input after receiving a 18x response and before the 200OK. IF I=20 >>>remember correctly calling FEDEX was actually one of the real life >examples. >>> >>>Regards >>>Andy >>> >>> >>>> -----Original Message----- >>>> From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] >>>> Sent: 19 February 2012 17:53 >>>> To: Cullen Jennings; Hutton, Andrew >>>> Cc: public-webrtc@w3.org; rtcweb@ietf.org >>>> Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >>>> >>>> Cullen, >>>> >>>> AFAIK, 18x with sendrecv as direction attribute & DTMF (telephony- >>>> event) is allowed by couple of operators in FEDEX (call center)=20 >>>> scenario. Andy will be able to double confirm whether he also comes=20 >>>> across the similar deployment. >>>> >>>> Thanks >>>> Partha >>>> >>>> >>>> >>>> >-----Original Message----- >>>> >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >>>> Behalf >>>> >Of Cullen Jennings >>>> >Sent: Saturday, February 18, 2012 2:29 AM >>>> >To: Hutton, Andrew >>>> >Cc: public-webrtc@w3.org; rtcweb@ietf.org >>>> >Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >>>> > >>>> > >>>> >On Feb 16, 2012, at 1:04 PM, Hutton, Andrew wrote: >>>> > >>>> >>> (Also, in the FEDEX case, there could be scenarios where the >>>> browser >>>> >>> does need to transit media, if the user is e.g. promted for=20 >>>> >>> DTMFs, voice commands etc...) >>>> >>> >>>> >> >>>> >> [AndyH] - I agree that media transmission is required at this=20 >>>> >> stage >>>> so >>>> >that the user can navigate through voice prompts (E.g. via DTMF) I=20 >>>> >thought this was the main requirement from the FEDEX use case. >>>> > >>>> >that's not my understanding. My understanding was it was one way=20 >>>> >media until the final response in the early media case. And the=20 >>>> >IVR sends >>>> the >>>> >first prompt as ringtone but cuts over before two way media (IE >>>> >DTMF) >>>> is >>>> >needed. The whole point of this hack is to cut the time the IVR=20 >>>> >gets billed for but the SP is not going to provide two way media=20 >>>> >before billing starts. >>>> > >>>> > >>>> >_______________________________________________ >>>> >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 Mon Feb 20 03:52: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 012DC21F8749 for ; Mon, 20 Feb 2012 03:52:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 RcsJToMWEvff for ; Mon, 20 Feb 2012 03:52:51 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 933AD21F872B for ; Mon, 20 Feb 2012 03:52:51 -0800 (PST) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q1KBrZuG013670; Mon, 20 Feb 2012 06:53:35 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 Feb 2012 06:52:47 -0500 Received: from INBA-HUB02.sonusnet.com ([10.70.51.87]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 Feb 2012 17:22:59 +0530 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, 20 Feb 2012 17:22:59 +0530 From: "Ravindran, Parthasarathi" To: Christer Holmberg , "Hutton, Andrew" , Cullen Jennings Thread-Topic: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case Thread-Index: AQHM7IE9KMJ367wTfUugOb7j2iGwS5Y/lw0AgAGhwICAA0qV0IAAPNUggACbz/CAAAEzEIAACBRAgAASIBCAAB2GgIAABh6AgAANu/CAAAYSQA== Date: Mon, 20 Feb 2012 11:52:58 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E040D32@inba-mail01.sonusnet.com> References: <7F2072F1E0DE894DA4B517B93C6A05852C3D87E060@ESESSCMS0356.eemea.ericsson.se> <3CBDF06F-F52D-4C09-A78F-1A0D8479572A@iii.ca> <7F2072F1E0DE894DA4B517B93C6A05852C3D87E58F@ESESSCMS0356.eemea.ericsson.se> <101C6067BEC68246B0C3F6843BCCC1E31202EDA663@MCHP058A.global-ad.net> <15CD1ECE-6BDD-4EE0-AA5B-EF40616578CD@iii.ca> <387F9047F55E8C42850AD6B3A7A03C6C0E040A1D@inba-mail01.sonusnet.com> <101C6067BEC68246B0C3F6843BCCC1E312942242CD@MCHP058A.global-ad.net> <7F2072F1E0DE894DA4B517B93C6A05852C3D8C60E1@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E040C04@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C3D8C6134@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E040C6D@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C3D8C630B@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E040CBF@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C3D914C49@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3D914C49@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.70] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 20 Feb 2012 11:52:59.0888 (UTC) FILETIME=[316FDF00:01CCEFC6] Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case 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, 20 Feb 2012 11:52:56 -0000 Hi Christer, I agree with you for the timer to release the unused offer resource from o= fferer browser if it is really a constraint. This timer helps browser from = badly designed webpage which sends offer but never complete answer. Let us = get more opinion on this. Timer mechanism shall be applicable with multiple SDP_ANSWER and there is n= o need of SDP_PRANSWER. The reason for requesting SDP_PRANSWER removal is t= o simplify O/A FSM in JS. In case SDP_ANSWER before timer expires, setRemo= teDescription returns success with updating answer in browser or else retur= n failure. Please let me know your opinion on the same. Thanks=20 Partha >-----Original Message----- >From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >Sent: Monday, February 20, 2012 4:46 PM >To: Ravindran, Parthasarathi; Hutton, Andrew; Cullen Jennings >Cc: rtcweb@ietf.org; public-webrtc@w3.org >Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case > > >Hi, > >There could always be a mechanism, where the broswer automatically >releases resources, if it hasn't received a SDP_ANSWER within a given >time. > >Regards, > >Christer > > >-----Original Message----- >From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] >Sent: 20. helmikuuta 2012 12:41 >To: Christer Holmberg; Hutton, Andrew; Cullen Jennings >Cc: rtcweb@ietf.org; public-webrtc@w3.org >Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case > >Hi Christer, > >It is obvious fact that mobile devices has limited resource. The >question is whether Mobile devices offer multiple codec during the >initial offer and waiting to release during the final answer for saving >memory resource. Final answer expecting design may have the impact >because the badly designed webpage may hog the system easily by just >sending offer & not mapping with answer and also in the scenario of >answerer reply with multiple codec. > >As part of SRTP discussion, Eric clarifies that Media security (SRTP) is >not an (CPU) performance issue in the endpoint. I could not understand >about ICE issues as ICE is triggered based on the number of answer apart >from the initial ICE procedure for offer. > >Thanks >Partha > >>-----Original Message----- >>From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>Sent: Monday, February 20, 2012 3:39 PM >>To: Ravindran, Parthasarathi; Hutton, Andrew; Cullen Jennings >>Cc: rtcweb@ietf.org; public-webrtc@w3.org >>Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >> >> >>Hi, >> >>Mobile devices (smartphones etc) will often have limited resources, no >>matter whether the app is running as a browser app or a native app. >> >>Also, codec was only one example. A better example is perhaps resources >>related to ICE, media security etc. >> >>Regards, >> >>Christer >> >> >>-----Original Message----- >>From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] >>Sent: 20. helmikuuta 2012 11:55 >>To: Christer Holmberg; Hutton, Andrew; Cullen Jennings >>Cc: rtcweb@ietf.org; public-webrtc@w3.org >>Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >> >>Hi Christer, >> >>Even I had thought through Cullen statement before reply to him in the >>another mail thread. As per your clarification, Each Codec (like g711 >>library, g729 library) will be loaded in the memory in the run-time >>based on offer and released based on the final answer for the memory >>saving. I agree that this mechanism is useful for DSP based VoIP >>endpoints wherein it is possible to load only one codec (or few codec) >>at the same time, mostly only one of the codec (first codec) will be >>loaded based on the answer and send Re-INVITE to indicate the committed >>codec in DSP. My understanding is that the same issue does not exists >>for WebRTC browser running in laptop, desktop and those devices will be >>capable of loading the multiple codec without impacting the system >>performance. Please correct me in case I misunderstand the system >>design here. I'm not very sure about Smartphone architecture w.r.t >>multiple codec handling. >> >>I have asked for 18x with SDP and 2xx without SDP scenario just to >>indicate the complication building up in the JavaScript offer/answer >>FSM because of the (provisional/final) response specific offer/answer >model. >> >>Thanks >>Partha >> >>>-----Original Message----- >>>From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>>Sent: Monday, February 20, 2012 12:51 PM >>>To: Ravindran, Parthasarathi; Hutton, Andrew; Cullen Jennings >>>Cc: rtcweb@ietf.org; public-webrtc@w3.org >>>Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >>> >>> >>>Hi, >>> >>>> IIUC, your proposal is to update JSEP SDP_PRANSWER and SDP_ANSWER as >>>> equivalent to moreComing=3Dtrue/false in ROAP. Also, we need to >>>> consider >>>the scenario like 18x with SDP (SDP_PRANSWER) and 2xx without SDP >>>wherein JS has to take care of SDP_ANSWER even though it does not >>>receive one. IMO, Multiple answer issue is not fully solved in ROAP as >>>well. >>> >>>In that case, I guess the JS app could simply take a previous >>>SDP_PRANSWER, and send it as SDP_ANSWER. >>> >>>> Also, I have the problem in the understanding the strong need for >>>differentiating answer and final answer. Could you please clarify it. >>> >>>I had exactly the same issue, but what Cullen told me last week made >>>me re-think. It's all about resources :) >>> >>>So, take the following example: >>> >>>1. The browser creates an offer, and reservers resrouces for codecs X >>>and Y. >>>2. At some point, the browser receives a PRANSWER, with only codec X. >>>However, the browser still keeps the resources for Y, as a new answer >>>may come. >>>3. At some point, the browser receives another PRANSWER (maybe forking >>>has occured), with only codec Y. However, the browser still keeps the >>>resources for X (again, as a new answer may come). >>>4. At some point, the browser recieves an ANSWER, with only codec X. >>>Now, as this is the last answer, the browser can release the resources >>>for Y. >>> >>>So, the main difference is related to the resources associated with >>>the offer. Once a final answer (ANSWER) has been received, and >>>resources that were reserved for the offer, but are no longer needed, >>>can be released. >>> >>>(Cullen, please correct me if I've missunderstood :) >>> >>>Regards, >>> >>>Christer >>> >>> >>>>-----Original Message----- >>>>From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>>>Sent: Monday, February 20, 2012 12:12 PM >>>>To: Hutton, Andrew; Ravindran, Parthasarathi; Cullen Jennings >>>>Cc: rtcweb@ietf.org; public-webrtc@w3.org >>>>Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >>>> >>>> >>>>Hi, >>>> >>>>In my opinion, even if we do need SDP_PRANSWER (Cullen may have >>>>convinced me that there is a need for it :), I don't think it should >>>>have an implicit "recvonly" meaning. >>>> >>>>PRANSWER or ANSWER, I think we shall use the SDP direction attribute >>>>(or some other explicit elements) to indicate media direction. >>>> >>>>Regards, >>>> >>>>Christer >>>> >>>> >>>> >>>>-----Original Message----- >>>>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >>>>Behalf Of Hutton, Andrew >>>>Sent: 19. helmikuuta 2012 23:26 >>>>To: Ravindran, Parthasarathi; Cullen Jennings >>>>Cc: rtcweb@ietf.org; public-webrtc@w3.org >>>>Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >>>> >>>>Hi, >>>> >>>>Yes absolutely I have come across a number of scenarios in the US and >>>>in Europe where media is needed in the forward direction for DTMF >>>>input after receiving a 18x response and before the 200OK. IF I >>>>remember correctly calling FEDEX was actually one of the real life >>examples. >>>> >>>>Regards >>>>Andy >>>> >>>> >>>>> -----Original Message----- >>>>> From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] >>>>> Sent: 19 February 2012 17:53 >>>>> To: Cullen Jennings; Hutton, Andrew >>>>> Cc: public-webrtc@w3.org; rtcweb@ietf.org >>>>> Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >>>>> >>>>> Cullen, >>>>> >>>>> AFAIK, 18x with sendrecv as direction attribute & DTMF (telephony- >>>>> event) is allowed by couple of operators in FEDEX (call center) >>>>> scenario. Andy will be able to double confirm whether he also comes >>>>> across the similar deployment. >>>>> >>>>> Thanks >>>>> Partha >>>>> >>>>> >>>>> >>>>> >-----Original Message----- >>>>> >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >>>>> Behalf >>>>> >Of Cullen Jennings >>>>> >Sent: Saturday, February 18, 2012 2:29 AM >>>>> >To: Hutton, Andrew >>>>> >Cc: public-webrtc@w3.org; rtcweb@ietf.org >>>>> >Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >>>>> > >>>>> > >>>>> >On Feb 16, 2012, at 1:04 PM, Hutton, Andrew wrote: >>>>> > >>>>> >>> (Also, in the FEDEX case, there could be scenarios where the >>>>> browser >>>>> >>> does need to transit media, if the user is e.g. promted for >>>>> >>> DTMFs, voice commands etc...) >>>>> >>> >>>>> >> >>>>> >> [AndyH] - I agree that media transmission is required at this >>>>> >> stage >>>>> so >>>>> >that the user can navigate through voice prompts (E.g. via DTMF) I >>>>> >thought this was the main requirement from the FEDEX use case. >>>>> > >>>>> >that's not my understanding. My understanding was it was one way >>>>> >media until the final response in the early media case. And the >>>>> >IVR sends >>>>> the >>>>> >first prompt as ringtone but cuts over before two way media (IE >>>>> >DTMF) >>>>> is >>>>> >needed. The whole point of this hack is to cut the time the IVR >>>>> >gets billed for but the SP is not going to provide two way media >>>>> >before billing starts. >>>>> > >>>>> > >>>>> >_______________________________________________ >>>>> >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 christer.holmberg@ericsson.com Mon Feb 20 05:00: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 8337F21F86FA for ; Mon, 20 Feb 2012 05:00:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.961 X-Spam-Level: X-Spam-Status: No, score=-9.961 tagged_above=-999 required=5 tests=[AWL=0.638, 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 oT1lAnA3I-Cu for ; Mon, 20 Feb 2012 05:00:05 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id BE3E021F86EE for ; Mon, 20 Feb 2012 05:00:04 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-99-4f4243d29318 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 9E.9D.01970.2D3424F4; Mon, 20 Feb 2012 14:00:02 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Mon, 20 Feb 2012 14:00:00 +0100 From: Christer Holmberg To: "Ravindran, Parthasarathi" , "Hutton, Andrew" , Cullen Jennings Date: Mon, 20 Feb 2012 13:59:59 +0100 Thread-Topic: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case Thread-Index: AQHM7IE9KMJ367wTfUugOb7j2iGwS5Y/lw0AgAGhwICAA0qV0IAAPNUggACbz/CAAAEzEIAACBRAgAASIBCAAB2GgIAABh6AgAANu/CAAAYSQIAAFwAw Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3D914D53@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C3D87E060@ESESSCMS0356.eemea.ericsson.se> <3CBDF06F-F52D-4C09-A78F-1A0D8479572A@iii.ca> <7F2072F1E0DE894DA4B517B93C6A05852C3D87E58F@ESESSCMS0356.eemea.ericsson.se> <101C6067BEC68246B0C3F6843BCCC1E31202EDA663@MCHP058A.global-ad.net> <15CD1ECE-6BDD-4EE0-AA5B-EF40616578CD@iii.ca> <387F9047F55E8C42850AD6B3A7A03C6C0E040A1D@inba-mail01.sonusnet.com> <101C6067BEC68246B0C3F6843BCCC1E312942242CD@MCHP058A.global-ad.net> <7F2072F1E0DE894DA4B517B93C6A05852C3D8C60E1@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E040C04@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C3D8C6134@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E040C6D@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C3D8C630B@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E040CBF@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C3D914C49@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E040D32@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E040D32@inba-mail01.sonusnet.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-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case 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, 20 Feb 2012 13:00:09 -0000 Hi, We can do it with timers, PRANSWER, or both. I just think the browser at so= me point shall be able to determine that there will be no more answers to a= given offer :) Regards, Christer=20 -----Original Message----- From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com]=20 Sent: 20. helmikuuta 2012 13:53 To: Christer Holmberg; Hutton, Andrew; Cullen Jennings Cc: rtcweb@ietf.org; public-webrtc@w3.org Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case Hi Christer, I agree with you for the timer to release the unused offer resource from o= fferer browser if it is really a constraint. This timer helps browser from = badly designed webpage which sends offer but never complete answer. Let us = get more opinion on this. Timer mechanism shall be applicable with multiple SDP_ANSWER and there is n= o need of SDP_PRANSWER. The reason for requesting SDP_PRANSWER removal is t= o simplify O/A FSM in JS. In case SDP_ANSWER before timer expires, setRemo= teDescription returns success with updating answer in browser or else retur= n failure. Please let me know your opinion on the same. Thanks Partha >-----Original Message----- >From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >Sent: Monday, February 20, 2012 4:46 PM >To: Ravindran, Parthasarathi; Hutton, Andrew; Cullen Jennings >Cc: rtcweb@ietf.org; public-webrtc@w3.org >Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case > > >Hi, > >There could always be a mechanism, where the broswer automatically=20 >releases resources, if it hasn't received a SDP_ANSWER within a given=20 >time. > >Regards, > >Christer > > >-----Original Message----- >From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] >Sent: 20. helmikuuta 2012 12:41 >To: Christer Holmberg; Hutton, Andrew; Cullen Jennings >Cc: rtcweb@ietf.org; public-webrtc@w3.org >Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case > >Hi Christer, > >It is obvious fact that mobile devices has limited resource. The=20 >question is whether Mobile devices offer multiple codec during the=20 >initial offer and waiting to release during the final answer for saving=20 >memory resource. Final answer expecting design may have the impact=20 >because the badly designed webpage may hog the system easily by just=20 >sending offer & not mapping with answer and also in the scenario of=20 >answerer reply with multiple codec. > >As part of SRTP discussion, Eric clarifies that Media security (SRTP)=20 >is not an (CPU) performance issue in the endpoint. I could not=20 >understand about ICE issues as ICE is triggered based on the number of=20 >answer apart from the initial ICE procedure for offer. > >Thanks >Partha > >>-----Original Message----- >>From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>Sent: Monday, February 20, 2012 3:39 PM >>To: Ravindran, Parthasarathi; Hutton, Andrew; Cullen Jennings >>Cc: rtcweb@ietf.org; public-webrtc@w3.org >>Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >> >> >>Hi, >> >>Mobile devices (smartphones etc) will often have limited resources, no=20 >>matter whether the app is running as a browser app or a native app. >> >>Also, codec was only one example. A better example is perhaps=20 >>resources related to ICE, media security etc. >> >>Regards, >> >>Christer >> >> >>-----Original Message----- >>From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] >>Sent: 20. helmikuuta 2012 11:55 >>To: Christer Holmberg; Hutton, Andrew; Cullen Jennings >>Cc: rtcweb@ietf.org; public-webrtc@w3.org >>Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >> >>Hi Christer, >> >>Even I had thought through Cullen statement before reply to him in the=20 >>another mail thread. As per your clarification, Each Codec (like g711=20 >>library, g729 library) will be loaded in the memory in the run-time=20 >>based on offer and released based on the final answer for the memory=20 >>saving. I agree that this mechanism is useful for DSP based VoIP=20 >>endpoints wherein it is possible to load only one codec (or few codec)=20 >>at the same time, mostly only one of the codec (first codec) will be=20 >>loaded based on the answer and send Re-INVITE to indicate the=20 >>committed codec in DSP. My understanding is that the same issue does=20 >>not exists for WebRTC browser running in laptop, desktop and those=20 >>devices will be capable of loading the multiple codec without=20 >>impacting the system performance. Please correct me in case I=20 >>misunderstand the system design here. I'm not very sure about=20 >>Smartphone architecture w.r.t multiple codec handling. >> >>I have asked for 18x with SDP and 2xx without SDP scenario just to=20 >>indicate the complication building up in the JavaScript offer/answer=20 >>FSM because of the (provisional/final) response specific offer/answer >model. >> >>Thanks >>Partha >> >>>-----Original Message----- >>>From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>>Sent: Monday, February 20, 2012 12:51 PM >>>To: Ravindran, Parthasarathi; Hutton, Andrew; Cullen Jennings >>>Cc: rtcweb@ietf.org; public-webrtc@w3.org >>>Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >>> >>> >>>Hi, >>> >>>> IIUC, your proposal is to update JSEP SDP_PRANSWER and SDP_ANSWER=20 >>>> as equivalent to moreComing=3Dtrue/false in ROAP. Also, we need to=20 >>>> consider >>>the scenario like 18x with SDP (SDP_PRANSWER) and 2xx without SDP=20 >>>wherein JS has to take care of SDP_ANSWER even though it does not=20 >>>receive one. IMO, Multiple answer issue is not fully solved in ROAP=20 >>>as well. >>> >>>In that case, I guess the JS app could simply take a previous=20 >>>SDP_PRANSWER, and send it as SDP_ANSWER. >>> >>>> Also, I have the problem in the understanding the strong need for >>>differentiating answer and final answer. Could you please clarify it. >>> >>>I had exactly the same issue, but what Cullen told me last week made=20 >>>me re-think. It's all about resources :) >>> >>>So, take the following example: >>> >>>1. The browser creates an offer, and reservers resrouces for codecs X=20 >>>and Y. >>>2. At some point, the browser receives a PRANSWER, with only codec X. >>>However, the browser still keeps the resources for Y, as a new answer=20 >>>may come. >>>3. At some point, the browser receives another PRANSWER (maybe=20 >>>forking has occured), with only codec Y. However, the browser still=20 >>>keeps the resources for X (again, as a new answer may come). >>>4. At some point, the browser recieves an ANSWER, with only codec X. >>>Now, as this is the last answer, the browser can release the=20 >>>resources for Y. >>> >>>So, the main difference is related to the resources associated with=20 >>>the offer. Once a final answer (ANSWER) has been received, and=20 >>>resources that were reserved for the offer, but are no longer needed,=20 >>>can be released. >>> >>>(Cullen, please correct me if I've missunderstood :) >>> >>>Regards, >>> >>>Christer >>> >>> >>>>-----Original Message----- >>>>From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>>>Sent: Monday, February 20, 2012 12:12 PM >>>>To: Hutton, Andrew; Ravindran, Parthasarathi; Cullen Jennings >>>>Cc: rtcweb@ietf.org; public-webrtc@w3.org >>>>Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >>>> >>>> >>>>Hi, >>>> >>>>In my opinion, even if we do need SDP_PRANSWER (Cullen may have=20 >>>>convinced me that there is a need for it :), I don't think it should=20 >>>>have an implicit "recvonly" meaning. >>>> >>>>PRANSWER or ANSWER, I think we shall use the SDP direction attribute=20 >>>>(or some other explicit elements) to indicate media direction. >>>> >>>>Regards, >>>> >>>>Christer >>>> >>>> >>>> >>>>-----Original Message----- >>>>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On=20 >>>>Behalf Of Hutton, Andrew >>>>Sent: 19. helmikuuta 2012 23:26 >>>>To: Ravindran, Parthasarathi; Cullen Jennings >>>>Cc: rtcweb@ietf.org; public-webrtc@w3.org >>>>Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >>>> >>>>Hi, >>>> >>>>Yes absolutely I have come across a number of scenarios in the US=20 >>>>and in Europe where media is needed in the forward direction for=20 >>>>DTMF input after receiving a 18x response and before the 200OK. IF I=20 >>>>remember correctly calling FEDEX was actually one of the real life >>examples. >>>> >>>>Regards >>>>Andy >>>> >>>> >>>>> -----Original Message----- >>>>> From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] >>>>> Sent: 19 February 2012 17:53 >>>>> To: Cullen Jennings; Hutton, Andrew >>>>> Cc: public-webrtc@w3.org; rtcweb@ietf.org >>>>> Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >>>>> >>>>> Cullen, >>>>> >>>>> AFAIK, 18x with sendrecv as direction attribute & DTMF (telephony- >>>>> event) is allowed by couple of operators in FEDEX (call center)=20 >>>>> scenario. Andy will be able to double confirm whether he also=20 >>>>> comes across the similar deployment. >>>>> >>>>> Thanks >>>>> Partha >>>>> >>>>> >>>>> >>>>> >-----Original Message----- >>>>> >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >>>>> Behalf >>>>> >Of Cullen Jennings >>>>> >Sent: Saturday, February 18, 2012 2:29 AM >>>>> >To: Hutton, Andrew >>>>> >Cc: public-webrtc@w3.org; rtcweb@ietf.org >>>>> >Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >>>>> > >>>>> > >>>>> >On Feb 16, 2012, at 1:04 PM, Hutton, Andrew wrote: >>>>> > >>>>> >>> (Also, in the FEDEX case, there could be scenarios where the >>>>> browser >>>>> >>> does need to transit media, if the user is e.g. promted for=20 >>>>> >>> DTMFs, voice commands etc...) >>>>> >>> >>>>> >> >>>>> >> [AndyH] - I agree that media transmission is required at this=20 >>>>> >> stage >>>>> so >>>>> >that the user can navigate through voice prompts (E.g. via DTMF)=20 >>>>> >I thought this was the main requirement from the FEDEX use case. >>>>> > >>>>> >that's not my understanding. My understanding was it was one way=20 >>>>> >media until the final response in the early media case. And the=20 >>>>> >IVR sends >>>>> the >>>>> >first prompt as ringtone but cuts over before two way media (IE >>>>> >DTMF) >>>>> is >>>>> >needed. The whole point of this hack is to cut the time the IVR=20 >>>>> >gets billed for but the SP is not going to provide two way media=20 >>>>> >before billing starts. >>>>> > >>>>> > >>>>> >_______________________________________________ >>>>> >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 Mon Feb 20 05: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 3B19821F86A6 for ; Mon, 20 Feb 2012 05:59:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 JXQEMQ0uK8Ob for ; Mon, 20 Feb 2012 05:59:47 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id B95A721F85F2 for ; Mon, 20 Feb 2012 05:59:46 -0800 (PST) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q1KE0UuA031145; Mon, 20 Feb 2012 09:00:30 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 Feb 2012 08:59:42 -0500 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 Feb 2012 19:29:55 +0530 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; Mon, 20 Feb 2012 19:29:54 +0530 From: "Ravindran, Parthasarathi" To: Christer Holmberg , "Hutton, Andrew" , Cullen Jennings Thread-Topic: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case Thread-Index: AQHM7IE9KMJ367wTfUugOb7j2iGwS5Y/lw0AgAGhwICAA0qV0IAAPNUggACbz/CAAAEzEIAACBRAgAASIBCAAB2GgIAABh6AgAANu/CAAAYSQIAAFwAwgAAOJ4A= Date: Mon, 20 Feb 2012 13:59:53 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E040DF7@inba-mail01.sonusnet.com> References: <7F2072F1E0DE894DA4B517B93C6A05852C3D87E060@ESESSCMS0356.eemea.ericsson.se> <3CBDF06F-F52D-4C09-A78F-1A0D8479572A@iii.ca> <7F2072F1E0DE894DA4B517B93C6A05852C3D87E58F@ESESSCMS0356.eemea.ericsson.se> <101C6067BEC68246B0C3F6843BCCC1E31202EDA663@MCHP058A.global-ad.net> <15CD1ECE-6BDD-4EE0-AA5B-EF40616578CD@iii.ca> <387F9047F55E8C42850AD6B3A7A03C6C0E040A1D@inba-mail01.sonusnet.com> <101C6067BEC68246B0C3F6843BCCC1E312942242CD@MCHP058A.global-ad.net> <7F2072F1E0DE894DA4B517B93C6A05852C3D8C60E1@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E040C04@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C3D8C6134@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E040C6D@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C3D8C630B@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E040CBF@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C3D914C49@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E040D32@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C3D914D53@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3D914D53@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.70] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 20 Feb 2012 13:59:55.0046 (UTC) FILETIME=[EC6CC460:01CCEFD7] Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case 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, 20 Feb 2012 13:59:51 -0000 Hi Christer, I agree for timers as it is inline with Proxy Timer C in SIP (RFC 3261). In= terms of SIP, Proxy Timer C helps to terminate INVITE request towards UAS = that never generates a final response. WebRTC client (browser) shall perfo= rm the similar functionality as there is no defined signaling entity. Thanks Partha=20 >-----Original Message----- >From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >Sent: Monday, February 20, 2012 6:30 PM >To: Ravindran, Parthasarathi; Hutton, Andrew; Cullen Jennings >Cc: rtcweb@ietf.org; public-webrtc@w3.org >Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case > > >Hi, > >We can do it with timers, PRANSWER, or both. I just think the browser at >some point shall be able to determine that there will be no more answers >to a given offer :) > >Regards, > >Christer > >-----Original Message----- >From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] >Sent: 20. helmikuuta 2012 13:53 >To: Christer Holmberg; Hutton, Andrew; Cullen Jennings >Cc: rtcweb@ietf.org; public-webrtc@w3.org >Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case > >Hi Christer, > >I agree with you for the timer to release the unused offer resource from >offerer browser if it is really a constraint. This timer helps browser >from badly designed webpage which sends offer but never complete answer. >Let us get more opinion on this. > >Timer mechanism shall be applicable with multiple SDP_ANSWER and there >is no need of SDP_PRANSWER. The reason for requesting SDP_PRANSWER >removal is to simplify O/A FSM in JS. In case SDP_ANSWER before timer >expires, setRemoteDescription returns success with updating answer in >browser or else return failure. Please let me know your opinion on the >same. > >Thanks >Partha > >>-----Original Message----- >>From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>Sent: Monday, February 20, 2012 4:46 PM >>To: Ravindran, Parthasarathi; Hutton, Andrew; Cullen Jennings >>Cc: rtcweb@ietf.org; public-webrtc@w3.org >>Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >> >> >>Hi, >> >>There could always be a mechanism, where the broswer automatically >>releases resources, if it hasn't received a SDP_ANSWER within a given >>time. >> >>Regards, >> >>Christer >> >> >>-----Original Message----- >>From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] >>Sent: 20. helmikuuta 2012 12:41 >>To: Christer Holmberg; Hutton, Andrew; Cullen Jennings >>Cc: rtcweb@ietf.org; public-webrtc@w3.org >>Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >> >>Hi Christer, >> >>It is obvious fact that mobile devices has limited resource. The >>question is whether Mobile devices offer multiple codec during the >>initial offer and waiting to release during the final answer for saving >>memory resource. Final answer expecting design may have the impact >>because the badly designed webpage may hog the system easily by just >>sending offer & not mapping with answer and also in the scenario of >>answerer reply with multiple codec. >> >>As part of SRTP discussion, Eric clarifies that Media security (SRTP) >>is not an (CPU) performance issue in the endpoint. I could not >>understand about ICE issues as ICE is triggered based on the number of >>answer apart from the initial ICE procedure for offer. >> >>Thanks >>Partha >> >>>-----Original Message----- >>>From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>>Sent: Monday, February 20, 2012 3:39 PM >>>To: Ravindran, Parthasarathi; Hutton, Andrew; Cullen Jennings >>>Cc: rtcweb@ietf.org; public-webrtc@w3.org >>>Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >>> >>> >>>Hi, >>> >>>Mobile devices (smartphones etc) will often have limited resources, no >>>matter whether the app is running as a browser app or a native app. >>> >>>Also, codec was only one example. A better example is perhaps >>>resources related to ICE, media security etc. >>> >>>Regards, >>> >>>Christer >>> >>> >>>-----Original Message----- >>>From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] >>>Sent: 20. helmikuuta 2012 11:55 >>>To: Christer Holmberg; Hutton, Andrew; Cullen Jennings >>>Cc: rtcweb@ietf.org; public-webrtc@w3.org >>>Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >>> >>>Hi Christer, >>> >>>Even I had thought through Cullen statement before reply to him in the >>>another mail thread. As per your clarification, Each Codec (like g711 >>>library, g729 library) will be loaded in the memory in the run-time >>>based on offer and released based on the final answer for the memory >>>saving. I agree that this mechanism is useful for DSP based VoIP >>>endpoints wherein it is possible to load only one codec (or few codec) >>>at the same time, mostly only one of the codec (first codec) will be >>>loaded based on the answer and send Re-INVITE to indicate the >>>committed codec in DSP. My understanding is that the same issue does >>>not exists for WebRTC browser running in laptop, desktop and those >>>devices will be capable of loading the multiple codec without >>>impacting the system performance. Please correct me in case I >>>misunderstand the system design here. I'm not very sure about >>>Smartphone architecture w.r.t multiple codec handling. >>> >>>I have asked for 18x with SDP and 2xx without SDP scenario just to >>>indicate the complication building up in the JavaScript offer/answer >>>FSM because of the (provisional/final) response specific offer/answer >>model. >>> >>>Thanks >>>Partha >>> >>>>-----Original Message----- >>>>From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>>>Sent: Monday, February 20, 2012 12:51 PM >>>>To: Ravindran, Parthasarathi; Hutton, Andrew; Cullen Jennings >>>>Cc: rtcweb@ietf.org; public-webrtc@w3.org >>>>Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >>>> >>>> >>>>Hi, >>>> >>>>> IIUC, your proposal is to update JSEP SDP_PRANSWER and SDP_ANSWER >>>>> as equivalent to moreComing=3Dtrue/false in ROAP. Also, we need to >>>>> consider >>>>the scenario like 18x with SDP (SDP_PRANSWER) and 2xx without SDP >>>>wherein JS has to take care of SDP_ANSWER even though it does not >>>>receive one. IMO, Multiple answer issue is not fully solved in ROAP >>>>as well. >>>> >>>>In that case, I guess the JS app could simply take a previous >>>>SDP_PRANSWER, and send it as SDP_ANSWER. >>>> >>>>> Also, I have the problem in the understanding the strong need for >>>>differentiating answer and final answer. Could you please clarify it. >>>> >>>>I had exactly the same issue, but what Cullen told me last week made >>>>me re-think. It's all about resources :) >>>> >>>>So, take the following example: >>>> >>>>1. The browser creates an offer, and reservers resrouces for codecs X >>>>and Y. >>>>2. At some point, the browser receives a PRANSWER, with only codec X. >>>>However, the browser still keeps the resources for Y, as a new answer >>>>may come. >>>>3. At some point, the browser receives another PRANSWER (maybe >>>>forking has occured), with only codec Y. However, the browser still >>>>keeps the resources for X (again, as a new answer may come). >>>>4. At some point, the browser recieves an ANSWER, with only codec X. >>>>Now, as this is the last answer, the browser can release the >>>>resources for Y. >>>> >>>>So, the main difference is related to the resources associated with >>>>the offer. Once a final answer (ANSWER) has been received, and >>>>resources that were reserved for the offer, but are no longer needed, >>>>can be released. >>>> >>>>(Cullen, please correct me if I've missunderstood :) >>>> >>>>Regards, >>>> >>>>Christer >>>> >>>> >>>>>-----Original Message----- >>>>>From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>>>>Sent: Monday, February 20, 2012 12:12 PM >>>>>To: Hutton, Andrew; Ravindran, Parthasarathi; Cullen Jennings >>>>>Cc: rtcweb@ietf.org; public-webrtc@w3.org >>>>>Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >>>>> >>>>> >>>>>Hi, >>>>> >>>>>In my opinion, even if we do need SDP_PRANSWER (Cullen may have >>>>>convinced me that there is a need for it :), I don't think it should >>>>>have an implicit "recvonly" meaning. >>>>> >>>>>PRANSWER or ANSWER, I think we shall use the SDP direction attribute >>>>>(or some other explicit elements) to indicate media direction. >>>>> >>>>>Regards, >>>>> >>>>>Christer >>>>> >>>>> >>>>> >>>>>-----Original Message----- >>>>>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >>>>>Behalf Of Hutton, Andrew >>>>>Sent: 19. helmikuuta 2012 23:26 >>>>>To: Ravindran, Parthasarathi; Cullen Jennings >>>>>Cc: rtcweb@ietf.org; public-webrtc@w3.org >>>>>Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >>>>> >>>>>Hi, >>>>> >>>>>Yes absolutely I have come across a number of scenarios in the US >>>>>and in Europe where media is needed in the forward direction for >>>>>DTMF input after receiving a 18x response and before the 200OK. IF I >>>>>remember correctly calling FEDEX was actually one of the real life >>>examples. >>>>> >>>>>Regards >>>>>Andy >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] >>>>>> Sent: 19 February 2012 17:53 >>>>>> To: Cullen Jennings; Hutton, Andrew >>>>>> Cc: public-webrtc@w3.org; rtcweb@ietf.org >>>>>> Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >>>>>> >>>>>> Cullen, >>>>>> >>>>>> AFAIK, 18x with sendrecv as direction attribute & DTMF (telephony- >>>>>> event) is allowed by couple of operators in FEDEX (call center) >>>>>> scenario. Andy will be able to double confirm whether he also >>>>>> comes across the similar deployment. >>>>>> >>>>>> Thanks >>>>>> Partha >>>>>> >>>>>> >>>>>> >>>>>> >-----Original Message----- >>>>>> >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >>>>>> Behalf >>>>>> >Of Cullen Jennings >>>>>> >Sent: Saturday, February 18, 2012 2:29 AM >>>>>> >To: Hutton, Andrew >>>>>> >Cc: public-webrtc@w3.org; rtcweb@ietf.org >>>>>> >Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >>>>>> > >>>>>> > >>>>>> >On Feb 16, 2012, at 1:04 PM, Hutton, Andrew wrote: >>>>>> > >>>>>> >>> (Also, in the FEDEX case, there could be scenarios where the >>>>>> browser >>>>>> >>> does need to transit media, if the user is e.g. promted for >>>>>> >>> DTMFs, voice commands etc...) >>>>>> >>> >>>>>> >> >>>>>> >> [AndyH] - I agree that media transmission is required at this >>>>>> >> stage >>>>>> so >>>>>> >that the user can navigate through voice prompts (E.g. via DTMF) >>>>>> >I thought this was the main requirement from the FEDEX use case. >>>>>> > >>>>>> >that's not my understanding. My understanding was it was one way >>>>>> >media until the final response in the early media case. And the >>>>>> >IVR sends >>>>>> the >>>>>> >first prompt as ringtone but cuts over before two way media (IE >>>>>> >DTMF) >>>>>> is >>>>>> >needed. The whole point of this hack is to cut the time the IVR >>>>>> >gets billed for but the SP is not going to provide two way media >>>>>> >before billing starts. >>>>>> > >>>>>> > >>>>>> >_______________________________________________ >>>>>> >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 juberti@google.com Mon Feb 20 07:12: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 69CE621F8746 for ; Mon, 20 Feb 2012 07:12:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.764 X-Spam-Level: X-Spam-Status: No, score=-102.764 tagged_above=-999 required=5 tests=[AWL=0.212, 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 Z2DoqH6KGVLX for ; Mon, 20 Feb 2012 07:12:30 -0800 (PST) Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id D80F821F8796 for ; Mon, 20 Feb 2012 07:12:29 -0800 (PST) Received: by qan41 with SMTP id 41so5973431qan.10 for ; Mon, 20 Feb 2012 07:12:29 -0800 (PST) Received-SPF: pass (google.com: domain of juberti@google.com designates 10.229.77.15 as permitted sender) client-ip=10.229.77.15; Authentication-Results: mr.google.com; spf=pass (google.com: domain of juberti@google.com designates 10.229.77.15 as permitted sender) smtp.mail=juberti@google.com; dkim=pass header.i=juberti@google.com Received: from mr.google.com ([10.229.77.15]) by 10.229.77.15 with SMTP id e15mr16462572qck.66.1329750749507 (num_hops = 1); Mon, 20 Feb 2012 07:12:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=7wJSe4mSSWnRWoi+reazgsXnCILfQ3TfRmQ16PMDHpA=; b=al08NXMYurx9DeFOcknFcC+nA9mYymSeWeIbe3vc/6+0D+AeGhQzHlnBueLBaOyak0 dxX4notuxTS8jmpnLE5CP587bVJNs/0rvOFFpKjfP5zTghA0JVIQh7HUHzHyWhsxKvmz 6bVJ+oRdl0Tr1D6+dO1zwxO2lRQjG2iRritac= Received: by 10.229.77.15 with SMTP id e15mr13977161qck.66.1329750748674; Mon, 20 Feb 2012 07:12:28 -0800 (PST) Received: by 10.229.77.15 with SMTP id e15mr13977135qck.66.1329750748378; Mon, 20 Feb 2012 07:12:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.29.195 with HTTP; Mon, 20 Feb 2012 07:12:08 -0800 (PST) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3D914D53@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C3D87E060@ESESSCMS0356.eemea.ericsson.se> <3CBDF06F-F52D-4C09-A78F-1A0D8479572A@iii.ca> <7F2072F1E0DE894DA4B517B93C6A05852C3D87E58F@ESESSCMS0356.eemea.ericsson.se> <101C6067BEC68246B0C3F6843BCCC1E31202EDA663@MCHP058A.global-ad.net> <15CD1ECE-6BDD-4EE0-AA5B-EF40616578CD@iii.ca> <387F9047F55E8C42850AD6B3A7A03C6C0E040A1D@inba-mail01.sonusnet.com> <101C6067BEC68246B0C3F6843BCCC1E312942242CD@MCHP058A.global-ad.net> <7F2072F1E0DE894DA4B517B93C6A05852C3D8C60E1@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E040C04@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C3D8C6134@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E040C6D@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C3D8C630B@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E040CBF@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C3D914C49@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E040D32@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C3D914D53@ESESSCMS0356.eemea.ericsson.se> From: Justin Uberti Date: Mon, 20 Feb 2012 10:12:08 -0500 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=00235446fe58ff3bd604b966b8f4 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkZ0qPhUqvibyyOWjMXcTQE8LDPxVjE7Pi+btCbGRV2/K7JH4o3WI3wfiP9qoMwVxYku76Qf65Ps/7Z1qsYFJVLyO89Y48esv1HNXA8u7c+q4GSfwjWCssYGMeTYqwfIojRSPjm1P1/ROlvCvUQcn3JaFsZeQ== Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case 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, 20 Feb 2012 15:12:34 -0000 --00235446fe58ff3bd604b966b8f4 Content-Type: text/plain; charset=UTF-8 Right; if we retain PRANSWER, I think "may have more answers in the future" should be its meaning, and applications can map things like 18x to PRANSWER, if desired. I agree that PRANSWER should not have implicit recvonly semantics, and we should use explicit directional attributes instead. On Mon, Feb 20, 2012 at 7:59 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > > Hi, > > We can do it with timers, PRANSWER, or both. I just think the browser at > some point shall be able to determine that there will be no more answers to > a given offer :) > > Regards, > > Christer > > -----Original Message----- > From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] > Sent: 20. helmikuuta 2012 13:53 > To: Christer Holmberg; Hutton, Andrew; Cullen Jennings > Cc: rtcweb@ietf.org; public-webrtc@w3.org > Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case > > Hi Christer, > > I agree with you for the timer to release the unused offer resource from > offerer browser if it is really a constraint. This timer helps browser > from badly designed webpage which sends offer but never complete answer. > Let us get more opinion on this. > > Timer mechanism shall be applicable with multiple SDP_ANSWER and there is > no need of SDP_PRANSWER. The reason for requesting SDP_PRANSWER removal is > to simplify O/A FSM in JS. In case SDP_ANSWER before timer expires, > setRemoteDescription returns success with updating answer in browser or > else return failure. Please let me know your opinion on the same. > > Thanks > Partha > > >-----Original Message----- > >From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > >Sent: Monday, February 20, 2012 4:46 PM > >To: Ravindran, Parthasarathi; Hutton, Andrew; Cullen Jennings > >Cc: rtcweb@ietf.org; public-webrtc@w3.org > >Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case > > > > > >Hi, > > > >There could always be a mechanism, where the broswer automatically > >releases resources, if it hasn't received a SDP_ANSWER within a given > >time. > > > >Regards, > > > >Christer > > > > > >-----Original Message----- > >From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] > >Sent: 20. helmikuuta 2012 12:41 > >To: Christer Holmberg; Hutton, Andrew; Cullen Jennings > >Cc: rtcweb@ietf.org; public-webrtc@w3.org > >Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case > > > >Hi Christer, > > > >It is obvious fact that mobile devices has limited resource. The > >question is whether Mobile devices offer multiple codec during the > >initial offer and waiting to release during the final answer for saving > >memory resource. Final answer expecting design may have the impact > >because the badly designed webpage may hog the system easily by just > >sending offer & not mapping with answer and also in the scenario of > >answerer reply with multiple codec. > > > >As part of SRTP discussion, Eric clarifies that Media security (SRTP) > >is not an (CPU) performance issue in the endpoint. I could not > >understand about ICE issues as ICE is triggered based on the number of > >answer apart from the initial ICE procedure for offer. > > > >Thanks > >Partha > > > >>-----Original Message----- > >>From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > >>Sent: Monday, February 20, 2012 3:39 PM > >>To: Ravindran, Parthasarathi; Hutton, Andrew; Cullen Jennings > >>Cc: rtcweb@ietf.org; public-webrtc@w3.org > >>Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case > >> > >> > >>Hi, > >> > >>Mobile devices (smartphones etc) will often have limited resources, no > >>matter whether the app is running as a browser app or a native app. > >> > >>Also, codec was only one example. A better example is perhaps > >>resources related to ICE, media security etc. > >> > >>Regards, > >> > >>Christer > >> > >> > >>-----Original Message----- > >>From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] > >>Sent: 20. helmikuuta 2012 11:55 > >>To: Christer Holmberg; Hutton, Andrew; Cullen Jennings > >>Cc: rtcweb@ietf.org; public-webrtc@w3.org > >>Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case > >> > >>Hi Christer, > >> > >>Even I had thought through Cullen statement before reply to him in the > >>another mail thread. As per your clarification, Each Codec (like g711 > >>library, g729 library) will be loaded in the memory in the run-time > >>based on offer and released based on the final answer for the memory > >>saving. I agree that this mechanism is useful for DSP based VoIP > >>endpoints wherein it is possible to load only one codec (or few codec) > >>at the same time, mostly only one of the codec (first codec) will be > >>loaded based on the answer and send Re-INVITE to indicate the > >>committed codec in DSP. My understanding is that the same issue does > >>not exists for WebRTC browser running in laptop, desktop and those > >>devices will be capable of loading the multiple codec without > >>impacting the system performance. Please correct me in case I > >>misunderstand the system design here. I'm not very sure about > >>Smartphone architecture w.r.t multiple codec handling. > >> > >>I have asked for 18x with SDP and 2xx without SDP scenario just to > >>indicate the complication building up in the JavaScript offer/answer > >>FSM because of the (provisional/final) response specific offer/answer > >model. > >> > >>Thanks > >>Partha > >> > >>>-----Original Message----- > >>>From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > >>>Sent: Monday, February 20, 2012 12:51 PM > >>>To: Ravindran, Parthasarathi; Hutton, Andrew; Cullen Jennings > >>>Cc: rtcweb@ietf.org; public-webrtc@w3.org > >>>Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case > >>> > >>> > >>>Hi, > >>> > >>>> IIUC, your proposal is to update JSEP SDP_PRANSWER and SDP_ANSWER > >>>> as equivalent to moreComing=true/false in ROAP. Also, we need to > >>>> consider > >>>the scenario like 18x with SDP (SDP_PRANSWER) and 2xx without SDP > >>>wherein JS has to take care of SDP_ANSWER even though it does not > >>>receive one. IMO, Multiple answer issue is not fully solved in ROAP > >>>as well. > >>> > >>>In that case, I guess the JS app could simply take a previous > >>>SDP_PRANSWER, and send it as SDP_ANSWER. > >>> > >>>> Also, I have the problem in the understanding the strong need for > >>>differentiating answer and final answer. Could you please clarify it. > >>> > >>>I had exactly the same issue, but what Cullen told me last week made > >>>me re-think. It's all about resources :) > >>> > >>>So, take the following example: > >>> > >>>1. The browser creates an offer, and reservers resrouces for codecs X > >>>and Y. > >>>2. At some point, the browser receives a PRANSWER, with only codec X. > >>>However, the browser still keeps the resources for Y, as a new answer > >>>may come. > >>>3. At some point, the browser receives another PRANSWER (maybe > >>>forking has occured), with only codec Y. However, the browser still > >>>keeps the resources for X (again, as a new answer may come). > >>>4. At some point, the browser recieves an ANSWER, with only codec X. > >>>Now, as this is the last answer, the browser can release the > >>>resources for Y. > >>> > >>>So, the main difference is related to the resources associated with > >>>the offer. Once a final answer (ANSWER) has been received, and > >>>resources that were reserved for the offer, but are no longer needed, > >>>can be released. > >>> > >>>(Cullen, please correct me if I've missunderstood :) > >>> > >>>Regards, > >>> > >>>Christer > >>> > >>> > >>>>-----Original Message----- > >>>>From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > >>>>Sent: Monday, February 20, 2012 12:12 PM > >>>>To: Hutton, Andrew; Ravindran, Parthasarathi; Cullen Jennings > >>>>Cc: rtcweb@ietf.org; public-webrtc@w3.org > >>>>Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case > >>>> > >>>> > >>>>Hi, > >>>> > >>>>In my opinion, even if we do need SDP_PRANSWER (Cullen may have > >>>>convinced me that there is a need for it :), I don't think it should > >>>>have an implicit "recvonly" meaning. > >>>> > >>>>PRANSWER or ANSWER, I think we shall use the SDP direction attribute > >>>>(or some other explicit elements) to indicate media direction. > >>>> > >>>>Regards, > >>>> > >>>>Christer > >>>> > >>>> > >>>> > >>>>-----Original Message----- > >>>>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > >>>>Behalf Of Hutton, Andrew > >>>>Sent: 19. helmikuuta 2012 23:26 > >>>>To: Ravindran, Parthasarathi; Cullen Jennings > >>>>Cc: rtcweb@ietf.org; public-webrtc@w3.org > >>>>Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case > >>>> > >>>>Hi, > >>>> > >>>>Yes absolutely I have come across a number of scenarios in the US > >>>>and in Europe where media is needed in the forward direction for > >>>>DTMF input after receiving a 18x response and before the 200OK. IF I > >>>>remember correctly calling FEDEX was actually one of the real life > >>examples. > >>>> > >>>>Regards > >>>>Andy > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] > >>>>> Sent: 19 February 2012 17:53 > >>>>> To: Cullen Jennings; Hutton, Andrew > >>>>> Cc: public-webrtc@w3.org; rtcweb@ietf.org > >>>>> Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case > >>>>> > >>>>> Cullen, > >>>>> > >>>>> AFAIK, 18x with sendrecv as direction attribute & DTMF (telephony- > >>>>> event) is allowed by couple of operators in FEDEX (call center) > >>>>> scenario. Andy will be able to double confirm whether he also > >>>>> comes across the similar deployment. > >>>>> > >>>>> Thanks > >>>>> Partha > >>>>> > >>>>> > >>>>> > >>>>> >-----Original Message----- > >>>>> >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > >>>>> Behalf > >>>>> >Of Cullen Jennings > >>>>> >Sent: Saturday, February 18, 2012 2:29 AM > >>>>> >To: Hutton, Andrew > >>>>> >Cc: public-webrtc@w3.org; rtcweb@ietf.org > >>>>> >Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case > >>>>> > > >>>>> > > >>>>> >On Feb 16, 2012, at 1:04 PM, Hutton, Andrew wrote: > >>>>> > > >>>>> >>> (Also, in the FEDEX case, there could be scenarios where the > >>>>> browser > >>>>> >>> does need to transit media, if the user is e.g. promted for > >>>>> >>> DTMFs, voice commands etc...) > >>>>> >>> > >>>>> >> > >>>>> >> [AndyH] - I agree that media transmission is required at this > >>>>> >> stage > >>>>> so > >>>>> >that the user can navigate through voice prompts (E.g. via DTMF) > >>>>> >I thought this was the main requirement from the FEDEX use case. > >>>>> > > >>>>> >that's not my understanding. My understanding was it was one way > >>>>> >media until the final response in the early media case. And the > >>>>> >IVR sends > >>>>> the > >>>>> >first prompt as ringtone but cuts over before two way media (IE > >>>>> >DTMF) > >>>>> is > >>>>> >needed. The whole point of this hack is to cut the time the IVR > >>>>> >gets billed for but the SP is not going to provide two way media > >>>>> >before billing starts. > >>>>> > > >>>>> > > >>>>> >_______________________________________________ > >>>>> >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 > --00235446fe58ff3bd604b966b8f4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Right; if we retain PRANSWER, I think "may have more answers in the fu= ture" should be its meaning, and applications can map things like 18x = to PRANSWER, if desired.

I agree that PRANSWER should no= t have implicit recvonly semantics, and we should use explicit directional = attributes instead.

On Mon, Feb 20, 2012 at 7:59 AM, Christer Ho= lmberg <christer.holmberg@ericsson.com> wrote:

Hi,

We can do it with timers, PRANSWER, or both. I just think the browser at so= me point shall be able to determine that there will be no more answers to a= given offer :)

Regards,

Christer

-----Original Message-----
From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com]
Sent: 20. helmikuuta 2012 13:= 53
To: Christer Holmberg; Hutton, Andrew; Cullen Jennings
Cc: rtcweb@ietf.org; public-webrtc@w3.org
Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case

Hi Christer,

I agree with you for the timer to release the unused offer resource from = =C2=A0offerer browser if it is really a constraint. This timer helps browse= r from badly designed webpage which sends offer but never complete answer. = Let us get more opinion on this.

Timer mechanism shall be applicable with multiple SDP_ANSWER and there is n= o need of SDP_PRANSWER. The reason for requesting SDP_PRANSWER removal is t= o simplify O/A FSM in JS. =C2=A0In case SDP_ANSWER before timer expires, se= tRemoteDescription returns success with updating answer in browser or else = return failure. Please let me know your opinion on the same.

Thanks
Partha

>-----Original Message-----
>From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
>Sent: Monday, February 20, 2012 4:46 PM
>To: Ravindran, Parthasarathi; Hutton, Andrew; Cullen Jennings
>Cc: rtcweb@ietf.org; public-webrtc@w3.org
>Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case
>
>
>Hi,
>
>There could always be a mechanism, where the broswer automatically
>releases resources, if it hasn't received a SDP_ANSWER within a giv= en
>time.
>
>Regards,
>
>Christer
>
>
>-----Original Message-----
>From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com]
>Sent: 20. helmikuuta 2012 12:41
>To: Christer Holmberg; Hutton, Andrew; Cullen Jennings
>Cc: rtcweb@ietf.org; public-webrtc@w3.org
>Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case
>
>Hi Christer,
>
>It is obvious fact that mobile devices has limited resource. The
>question is whether Mobile devices offer multiple codec during the
>initial offer and waiting to release during the final answer for saving=
>memory resource. Final answer expecting design may have the impact
>because the badly designed webpage may hog the system easily by just >sending offer & not mapping with answer and also in the scenario of=
>answerer reply with multiple codec.
>
>As part of SRTP discussion, Eric clarifies that Media security (SRTP) >is not an (CPU) performance issue in the endpoint. I could not
>understand about ICE issues as ICE is triggered based on the number of<= br> >answer apart from the initial ICE procedure for offer.
>
>Thanks
>Partha
>
>>-----Original Message-----
>>From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
>>Sent: Monday, February 20, 2012 3:39 PM
>>To: Ravindran, Parthasarathi; Hutton, Andrew; Cullen Jennings
>>Cc: rtcweb@ietf.org; public-webrtc@w3.org
>>Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case
>>
>>
>>Hi,
>>
>>Mobile devices (smartphones etc) will often have limited resources,= no
>>matter whether the app is running as a browser app or a native app.=
>>
>>Also, codec was only one example. A better example is perhaps
>>resources related to ICE, media security etc.
>>
>>Regards,
>>
>>Christer
>>
>>
>>-----Original Message-----
>>From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com]
>>Sent: 20. helmikuuta 2012 11:55
>>To: Christer Holmberg; Hutton, Andrew; Cullen Jennings
>>Cc: rtcweb@ietf.org; public-webrtc@w3.org
>>Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case
>>
>>Hi Christer,
>>
>>Even I had thought through Cullen statement before reply to him in = the
>>another mail thread. As per your clarification, Each Codec (like g7= 11
>>library, g729 library) will be loaded in the memory in the run-time=
>>based on offer and released based on the final answer for the memor= y
>>saving. I agree that this mechanism is useful for DSP based VoIP >>endpoints wherein it is possible to load only one codec (or few cod= ec)
>>at the same time, mostly only one of the codec (first codec) will b= e
>>loaded based on the answer and send Re-INVITE to indicate the
>>committed codec in DSP. My understanding is that the same issue doe= s
>>not exists for WebRTC browser running in laptop, desktop and those<= br> >>devices will be capable of loading the multiple codec without
>>impacting the system performance. Please correct me in case I
>>misunderstand the system design here. I'm not very sure about >>Smartphone architecture w.r.t multiple codec handling.
>>
>>I have asked for 18x with SDP and 2xx without SDP scenario just to<= br> >>indicate the complication building up in the JavaScript offer/answe= r
>>FSM because of the (provisional/final) response specific offer/answ= er
>model.
>>
>>Thanks
>>Partha
>>
>>>-----Original Message-----
>>>From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
>>>Sent: Monday, February 20, 2012 12:51 PM
>>>To: Ravindran, Parthasarathi; Hutton, Andrew; Cullen Jennings >>>Cc: rtcweb@ietf.org; public-webrtc@w3.org
>>>Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case<= br> >>>
>>>
>>>Hi,
>>>
>>>> IIUC, your proposal is to update JSEP SDP_PRANSWER and SDP= _ANSWER
>>>> as equivalent to moreComing=3Dtrue/false in ROAP. Also, we= need to
>>>> consider
>>>the scenario like 18x with SDP (SDP_PRANSWER) and 2xx without S= DP
>>>wherein JS has to take care of SDP_ANSWER even though it does n= ot
>>>receive one. IMO, Multiple answer issue is not fully solved in = ROAP
>>>as well.
>>>
>>>In that case, I guess the JS app could simply take a previous >>>SDP_PRANSWER, and send it as SDP_ANSWER.
>>>
>>>> Also, I have the problem in the understanding the strong n= eed for
>>>differentiating answer and final answer. Could you please clari= fy it.
>>>
>>>I had exactly the same issue, but what Cullen told me last week= made
>>>me re-think. It's all about resources :)
>>>
>>>So, take the following example:
>>>
>>>1. The browser creates an offer, and reservers resrouces for co= decs X
>>>and Y.
>>>2. At some point, the browser receives a PRANSWER, with only co= dec X.
>>>However, the browser still keeps the resources for Y, as a new = answer
>>>may come.
>>>3. At some point, the browser receives another PRANSWER (maybe<= br> >>>forking has occured), with only codec Y. However, the browser s= till
>>>keeps the resources for X (again, as a new answer may come). >>>4. At some point, the browser recieves an ANSWER, with only cod= ec X.
>>>Now, as this is the last answer, the browser can release the >>>resources for Y.
>>>
>>>So, the main difference is related to the resources associated = with
>>>the offer. Once a final answer (ANSWER) has been received, and<= br> >>>resources that were reserved for the offer, but are no longer n= eeded,
>>>can be released.
>>>
>>>(Cullen, please correct me if I've missunderstood :)
>>>
>>>Regards,
>>>
>>>Christer
>>>
>>>
>>>>-----Original Message-----
>>>>From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
>>>>Sent: Monday, February 20, 2012 12:12 PM
>>>>To: Hutton, Andrew; Ravindran, Parthasarathi; Cullen Jennin= gs
>>>>Cc: rtcweb@ietf.org;= public-webrtc@w3.org
>>>>Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-c= ase
>>>>
>>>>
>>>>Hi,
>>>>
>>>>In my opinion, even if we do need SDP_PRANSWER (Cullen may = have
>>>>convinced me that there is a need for it :), I don't th= ink it should
>>>>have an implicit "recvonly" meaning.
>>>>
>>>>PRANSWER or ANSWER, I think we shall use the SDP direction = attribute
>>>>(or some other explicit elements) to indicate media directi= on.
>>>>
>>>>Regards,
>>>>
>>>>Christer
>>>>
>>>>
>>>>
>>>>-----Original Message-----
>>>>From: rtcweb-bou= nces@ietf.org [mailto:rtcweb= -bounces@ietf.org] On
>>>>Behalf Of Hutton, Andrew
>>>>Sent: 19. helmikuuta 2012 23:26
>>>>To: Ravindran, Parthasarathi; Cullen Jennings
>>>>Cc: rtcweb@ietf.org;= public-webrtc@w3.org
>>>>Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-c= ase
>>>>
>>>>Hi,
>>>>
>>>>Yes absolutely I have come across a number of scenarios in = the US
>>>>and in Europe where media is needed in the forward directio= n for
>>>>DTMF input after receiving a 18x response and before the 20= 0OK. IF I
>>>>remember correctly calling FEDEX was actually one of the re= al life
>>examples.
>>>>
>>>>Regards
>>>>Andy
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com]
>>>>> Sent: 19 February 2012 17:53
>>>>> To: Cullen Jennings; Hutton, Andrew
>>>>> Cc: public-web= rtc@w3.org; rtcweb@ietf.org
>>>>> Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX = use-case
>>>>>
>>>>> Cullen,
>>>>>
>>>>> AFAIK, 18x with sendrecv as direction attribute & = DTMF (telephony-
>>>>> event) is allowed by couple of operators in FEDEX (cal= l center)
>>>>> scenario. Andy will be able to double confirm whether = he also
>>>>> comes across the similar deployment.
>>>>>
>>>>> Thanks
>>>>> Partha
>>>>>
>>>>>
>>>>>
>>>>> >-----Original Message-----
>>>>> >From: r= tcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
>>>>> Behalf
>>>>> >Of Cullen Jennings
>>>>> >Sent: Saturday, February 18, 2012 2:29 AM
>>>>> >To: Hutton, Andrew
>>>>> >Cc: public= -webrtc@w3.org; rtcweb@ietf.org<= br> >>>>> >Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FE= DEX use-case
>>>>> >
>>>>> >
>>>>> >On Feb 16, 2012, at 1:04 PM, Hutton, Andrew wrote:=
>>>>> >
>>>>> >>> (Also, in the FEDEX case, there could be = scenarios where the
>>>>> browser
>>>>> >>> does need to transit media, if the user i= s e.g. promted for
>>>>> >>> DTMFs, voice commands etc...)
>>>>> >>>
>>>>> >>
>>>>> >> [AndyH] - I agree that media transmission is = required at this
>>>>> >> stage
>>>>> so
>>>>> >that the user can navigate through voice prompts (= E.g. via DTMF)
>>>>> >I thought this was the main requirement from the F= EDEX use case.
>>>>> >
>>>>> >that's not my understanding. My understanding = was it was one way
>>>>> >media until the final response in the early media = case. And the
>>>>> >IVR sends
>>>>> the
>>>>> >first prompt as ringtone but cuts over before two = way media (IE
>>>>> >DTMF)
>>>>> is
>>>>> >needed. The whole point of this hack is to cut the= time the IVR
>>>>> >gets billed for but the SP is not going to provide= two way media
>>>>> >before billing starts.
>>>>> >
>>>>> >
>>>>> >_______________________________________________ >>>>> >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

--00235446fe58ff3bd604b966b8f4-- From sohel_khan@cable.comcast.com Mon Feb 20 07:19: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 F0C0E21F8548 for ; Mon, 20 Feb 2012 07:19:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.831 X-Spam-Level: X-Spam-Status: No, score=-101.831 tagged_above=-999 required=5 tests=[AWL=-3.015, BAYES_40=-0.185, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GnEy-N1nvlln for ; Mon, 20 Feb 2012 07:19:01 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9CC21F84BF for ; Mon, 20 Feb 2012 07:19:01 -0800 (PST) Received: from ([24.40.56.116]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.6681145; Mon, 20 Feb 2012 08:08:41 -0700 Received: from PACDCEXMB02.cable.comcast.com ([fe80::9803:aba4:1ac8:474e]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%15]) with mapi id 14.01.0355.002; Mon, 20 Feb 2012 10:18:59 -0500 From: "Khan, Sohel" To: "rtcweb@ietf.org" Thread-Topic: draft-ietf-rtcweb-security-arch-00 Thread-Index: Aczv21xh2pHouKjZSAeypXuScTchkQ== Date: Mon, 20 Feb 2012 15:18:58 +0000 Deferred-Delivery: Mon, 20 Feb 2012 15:18:00 +0000 Message-ID: <837E772D16C77141BFA5FEC3F30487FF525BF54C@PACDCEXMB02.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.40.56.171] Content-Type: multipart/alternative; boundary="_000_837E772D16C77141BFA5FEC3F30487FF525BF54CPACDCEXMB02cabl_" MIME-Version: 1.0 Subject: [rtcweb] draft-ietf-rtcweb-security-arch-00 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, 20 Feb 2012 15:19:02 -0000 --_000_837E772D16C77141BFA5FEC3F30487FF525BF54CPACDCEXMB02cabl_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Eric and others, Thank you for the RTCWEB Security Architecture draft. Some SIP or telco-cen= tric implementers may need to understand the RTCWeb trust model visualizing= in the context of SIP REGISTER method. Would it be possible to add a secti= on in your draft with an example describing the Web Trust model that might = be used for the RTCWeb and compare/contrast that with SIP REGISTER method?= This section will be very beneficial to the SIP or telco-centric implemen= ters, who are used to SIP REGISTER trust model. Thank you. Sohel Khan --_000_837E772D16C77141BFA5FEC3F30487FF525BF54CPACDCEXMB02cabl_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Eric and others,

 

Thank you for the RTCWEB Security Architecture draft= . Some SIP or telco-centric implementers may need to understand the RTCWeb = trust model visualizing in the context of SIP REGISTER method. Would it be = possible to add a section in your draft with an example describing the Web Trust model that might be used fo= r the  RTCWeb and compare/contrast that with SIP REGISTER method? &nbs= p;This section will be very beneficial to the SIP or telco-centric implemen= ters, who are used to SIP REGISTER trust model.

 

Thank you.

Sohel Khan

--_000_837E772D16C77141BFA5FEC3F30487FF525BF54CPACDCEXMB02cabl_-- From ibc@aliax.net Mon Feb 20 07:46: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 6971121F874C for ; Mon, 20 Feb 2012 07:46:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[AWL=0.059, 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 H8DDV8vDsRyx for ; Mon, 20 Feb 2012 07:46:00 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id AC0B321F8753 for ; Mon, 20 Feb 2012 07:46:00 -0800 (PST) Received: by ghbg16 with SMTP id g16so2976743ghb.31 for ; Mon, 20 Feb 2012 07:46:00 -0800 (PST) Received-SPF: pass (google.com: domain of ibc@aliax.net designates 10.236.182.232 as permitted sender) client-ip=10.236.182.232; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ibc@aliax.net designates 10.236.182.232 as permitted sender) smtp.mail=ibc@aliax.net Received: from mr.google.com ([10.236.182.232]) by 10.236.182.232 with SMTP id o68mr29014604yhm.58.1329752760259 (num_hops = 1); Mon, 20 Feb 2012 07:46:00 -0800 (PST) Received: by 10.236.182.232 with SMTP id o68mr22331981yhm.58.1329752760175; Mon, 20 Feb 2012 07:46:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.252.16 with HTTP; Mon, 20 Feb 2012 07:45:40 -0800 (PST) In-Reply-To: <837E772D16C77141BFA5FEC3F30487FF525BF54C@PACDCEXMB02.cable.comcast.com> References: <837E772D16C77141BFA5FEC3F30487FF525BF54C@PACDCEXMB02.cable.comcast.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 20 Feb 2012 16:45:40 +0100 Message-ID: To: "Khan, Sohel" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQn3j6C4jOUMDg9GBlG/Jb9Hs437njVmF6wp6eOkKQlU0BfvNMoYUAEaJk6k950Y8G1p7DN0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-security-arch-00 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, 20 Feb 2012 15:46:01 -0000 2012/2/20 Khan, Sohel : > Thank you for the RTCWEB Security Architecture draft. Some SIP or > telco-centric implementers may need to understand the RTCWeb trust model > visualizing in the context of SIP REGISTER method. Would it be possible t= o > add a section in your draft with an example describing the Web Trust mode= l > that might be used for the =C2=A0RTCWeb and compare/contrast that with SI= P > REGISTER method? =C2=A0This section will be very beneficial to the SIP or > telco-centric implementers, who are used to SIP REGISTER trust model. I would just send a real SIP REGISTER request via WebSocket :) --=20 I=C3=B1aki Baz Castillo From mperumal@cisco.com Mon Feb 20 10:19: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 DD84021F85C5 for ; Mon, 20 Feb 2012 10:19:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.169 X-Spam-Level: X-Spam-Status: No, score=-7.169 tagged_above=-999 required=5 tests=[AWL=1.570, BAYES_20=-0.74, 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 64NloGWQodqS for ; Mon, 20 Feb 2012 10:19:07 -0800 (PST) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id 71A4C21F8559 for ; Mon, 20 Feb 2012 10:19:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=61730; q=dns/txt; s=iport; t=1329761943; x=1330971543; h=mime-version:subject:date:message-id:from:to:cc; bh=ttx/Z4Ua3GYlXCPvWkbjlG4lINHxquMa0XdMzXuRfi0=; b=PfQitmXcfv5IqLUskjBHT6qL1+yvUuGm7AefA9GbTbAfoxGIEuUD0+kH DUnMyPCAYTBRcFF2H+cVxoNV2eJ34m7DBbADRq6p5X0UsOYYMxsIvM+28 C6b4a0UPo+Ajd6Zi90g/FJjqrDQb70GFO4S3DscNfAQbaK61PRsXojz3P g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoFAMSNQk9Io8UY/2dsb2JhbABEFoI3nhOIFAGKDYFsBwEBAQICEgEFBBEDNwEREgEIEQQBAQsGBQsBBgEHJSAHAQEFBAEECwcBCBqFJoJBmnUBnn+LfwgBEQWEDRQQAjMagkdjBIJdhT4xjR2SQw X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208,217";a="5974354" Received: from vla196-nat.cisco.com (HELO bgl-core-2.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 20 Feb 2012 18:19:01 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q1KIJ1B7015784; Mon, 20 Feb 2012 18:19:01 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 Feb 2012 23:49:01 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCEFFC.1E7DDFC1" x-cr-hashedpuzzle: B6YR EHUZ FL3F Gvy1 Hosc KpEl KuMc NeOT VnjQ eatE e7Z+ g3Ha wAgG wUnc xXQF 1vOy; 5; ZwBvAG4AegBhAGwAbwAuAGMAYQBtAGEAcgBpAGwAbABvAEAAZQByAGkAYwBzAHMAbwBuAC4AYwBvAG0AOwBqAHIAdQBpAHoAQAB1AG4AaQB6AGEAcgAuAGUAcwA7AGoAcwBhAGwAZABhAG4AYQBAAHUAbgBpAHoAYQByAC4AZQBzADsAbgBhAHYAYQBqAGEAcwBAAHUAbgBpAHoAYQByAC4AZQBzADsAcgB0AGMAdwBlAGIAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {A70333F0-63AE-41BC-9F63-85B6DAAE4014}; bQBwAGUAcgB1AG0AYQBsAEAAYwBpAHMAYwBvAC4AYwBvAG0A; Mon, 20 Feb 2012 18:18:16 GMT; RgBXADoAIABQAHIAbwBwAG8AcwBhAGwAIABmAG8AcgAgAHQAdQBuAG4AZQBsAGkAbgBnACwAIABjAG8AbQBwAHIAZQBzAHMAaQBuAGcAIABhAG4AZAAgAG0AdQBsAHQAaQBwAGwAZQB4AGkAbgBnACAAZgBsAG8AdwBzAA== x-cr-puzzleid: {A70333F0-63AE-41BC-9F63-85B6DAAE4014} Content-class: urn:content-classes:message Date: Mon, 20 Feb 2012 23:48:16 +0530 Message-ID: <1D062974A4845E4D8A343C6538049202079972BB@XMB-BGL-414.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposal for tunneling, compressing and multiplexing flows Thread-Index: AczswLd3PRcbh2KZSVuIavP07AhIHADOelwA From: "Muthu Arul Mozhi Perumal (mperumal)" To: X-OriginalArrivalTime: 20 Feb 2012 18:19:01.0644 (UTC) FILETIME=[1EEB5CC0:01CCEFFC] Cc: jsaldana@unizar.es, "Michael Ramalho \(mramalho\)" , =?iso-8859-1?Q?Juli=E1n_Fern=E1ndez_Navajas?= , =?iso-8859-1?Q?Jos=E9_Ruiz?= Subject: [rtcweb] FW: Proposal for tunneling, compressing and multiplexing flows 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, 20 Feb 2012 18:19:12 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCEFFC.1E7DDFC1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Any thoughts on how important this is for WebRTC? =20 Muthu =20 From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf = Of Jose Saldana Sent: Thursday, February 16, 2012 9:17 PM To: tsvwg@ietf.org Subject: Proposal for tunneling, compressing and multiplexing flows =20 Hello all. =20 My name is Jose Saldana, from the University of Zaragoza, in Spain. I am = new in this workgroup. =20 Today I have uploaded a new draft: = http://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/: =20 Title : Tunneling Compressed Multiplexed = Traffic Flows (TCMTF) Author(s) : Jose Saldana Filename : draft-saldana-tsvwg-tcmtf-00.txt Pages : 16 Date : 2012-02-16 =20 I am not the sole author of the draft. In fact, six more people have = contributed to build it: Dan Wing (Cisco), Julian Fernandez-Navajas = (Univ. of Zaragoza), Jose Ruiz-Mas (Univ. of Zaragoza), Muthu A. M. = Perumal (Cisco), Gonzalo Camarillo (Ericsson) and Michael = Ramalho(Cisco). =20 Abstract: This document describes a method to improve the bandwidth = utilization of network paths that carry multiple streams in parallel = between two endpoints, as in voice trunking. The method combines = standard protocols that provide compression, multiplexing, and = tunneling over a network path for the purpose of reducing the bandwidth = used when multiple streams are carried over that path. =20 The main idea is to update TCRTP. This is a "Best current practice" RFC = (http://datatracker.ietf.org/doc/rfc4170 = ) which was developed in = Audio/Video Transport working group in 2005-11. It "describes a method = to improve the bandwidth utilization of RTP streams over network paths = that carry multiple Real-time Transport Protocol (RTP) streams in = parallel between two endpoints, as in voice trunking. The method = combines standard protocols that provide compression, multiplexing, and = tunneling over a network path for the purpose of reducing the bandwidth = used when multiple RTP streams are carried over that path." (from the = introduction of RFC4170). =20 The scheme of TCRTP is: =20 RTP/UDP/IP | | ECRTP (compressing layer). Compresses RTP/UDP/IP headers | | PPPMux (multiplexing layer). Includes a number of compressed = packets into a bigger one | | L2TP (tunneling layer). Permits its use end-to-end | | IP =20 However, there exist many real-time flows that do not use RTP: =20 - Online "First Person Shooter" (FPS) games use UDP datagrams, and they = are one of the most "real-time" applications nowadays. Some examples: = Counter Strike, Halo, Quake, etc.[1]. =20 - Online "Massively Multiplayer Online Role Playing Games" (MMORPG): = They use TCP, but can be considered "real-time", since the actions of = the players have to be transmitted very quickly to the server. It should = be taken into account that player vs player fights are one of the = possible activities of the game. Some examples: World of Warcraft (more = than 10 million subscribers) [2]. =20 - TCP is also getting used for media delivery. For many reasons, such as = avoiding firewalls, the standard IP/ UDP/ RTP protocol stack is = substituted in many cases by IP/ TCP/ HTTP/ FLV [3]. =20 - Another interesting scenario is satellite communication links. = Multiplexing small packets into one packet for transmission would = improve the efficiency. Satellite links would also find it useful to = multiplex small TCP packets into one packet - this could be especially = interesting for compressing TCP ACKs. =20 =20 In our recent research activities, we have adapted TCRTP scheme for its = use when the traffic is not RTP. The idea is to substitute ECRTP by = other compression scheme which can be used for UDP or TCP headers. In = 2006, the IETF formed the Robust Header Compression (ROHC) working group = which created specifications for header compression over links for RTP, = UDP and TCP. These specifications were extended to compress headers = over other networks. For most RTP flows, ROHC is more bandwidth = efficient than ECRTP, at the cost of implementation complexity. It has a = special care of context synchronization, defining some states at the = compressor and decompressor. Once the effort for designing ROHC has been = conducted, it is worth including it in the compressing and multiplexing = standard. =20 In a recent paper in Nov. issue of IEEE Communications Magazine, it was = shown that 30% of bandwidth saving can be achieved for 8 FPS different = games using IPv4. If IPv6 is used, savings can be up to 54% [4]. Another = recent study, which is still under review, has estimated 45% bandwidth = saving for World of Warcraft. =20 After working with other researchers, we have developed a standard. The = possible scheme of the proposal could be this one: =20 G.711 or other payload | ------------------------------ | G.711.0 or other payload compression payload compression layer | | ------------------------------ TCP UDP RTP/UDP | | | \ | / ------------------------------ \ | / Nothing or ROHC or ECRTP or IPHC header compressing layer | | ------------------------------ | PPPMUX or other mux protocols multiplexing layer | | ------------------------------ | GRE or L2TP or other tunneling layer | | ------------------------------ IP =20 It should be more "open" than TCRTP. I the use of different protocols = could be "orthogonal": different header compression algorithms could be = used, depending on the application and the scenario; also different = multiplexing and tunneling protocols could be included. Finally, another = option has been considered: A payload compression layer. When the = payload is G.711 this layer can runs G.711.0, a lossless and stateless = compression/decompression of the payload [I.711]. This operations can = be deployed by network elements like routers/switches, without the = endpoints having to signal it using RTSP/SDP/SIP, since G.711 has a = fixed RTP payload number. =20 Regarding the scenarios, we have considered some of them: =20 - A provider of a real-time service (e.g. game or voip) can have an = infrastructure with a number of proxies that can group traffic from = different users and send it to the server. =20 - An Internet caf=E9, where a number (sometimes big) of players share = the same access link. Bandwidth is scarce in that scenario. =20 - A satellite link, where the bandwidth and the pps have to be saved. =20 - Desktop or application sharing where the traffic from the server to = the client typically consists of the delta of screen updates. Also, the = standard for remote desktop sharing emerging for WebRTC in the RTCWEB = Working Group is: {something}/SCTP/UDP (Stream Control Transmission = Protocol [SCTP]). In this scenario, SCTP/UDP could be used in other = cases: chatting, file sharing and applications related to WebRTC peers. = There could be hundreds of clients at a site talking to a server located = at a datacenter over a WAN. =20 Thank you very much, and sorry for writing such a long message, =20 Jose Saldana University of Zaragoza =20 PS: We have also written a paper, which will be presented in next ICC = conference, in Ottawa in June. You can read a draft here: = http://diec.unizar.es/~jsaldana/personal/widening_scope_draft.pdf =20 ______________ =20 [1] Ratti, S.; Hariri, B.; Shirmohammadi, S., "A Survey of First-Person = Shooter Gaming Traffic on the Internet," Internet Computing, IEEE , = vol.14, no.5, pp.60-69, Sept.-Oct. 2010. URL: = http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D&arnumber=3D5445069&isnum= ber=3D5562482 = =20 =20 [2] P. Svoboda, W Karner and M. Rupp, "Traffic Analysis and Modeling for = World of Warcraft," ICC '07. IEEE International Conference on = Communications, pp.1612-1617, 24-28, Jun. 2007. URL: = http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D&arnumber=3D4288941&isnum= ber=3D4288671 = =20 =20 [3] G. Marfia and M. Roccetti, "TCP At Last: Reconsidering TCP's Role = for Wireless Entertainment Centers at Home," IEEE Transactions on = Consumer Electronics, Vol. 56, N. 4, Nov. 2010, pp. 2233-2240. URL: = http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D&arnumber=3D5681095&isnum= ber=3D5681060 = =20 =20 [4] J. Saldana, J. Fern=E1ndez-Navajas, J. Ruiz-Mas, J. I. Aznar, E. = Viruete and L. Casadesus, "First Person Shooters: Can a Smarter Network = Save Bandwidth without Annoying the Players?," IEEE Communications = Magazine, Consumer Communications and Networking Series, vol. 49, no. 11, pp. 190-198, Nov. 2011. URL: = http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D&arnumber=3D6069728&isnum= ber=3D6069696 = =20 =20 =20 ------_=_NextPart_001_01CCEFFC.1E7DDFC1 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Any = thoughts on how important this is for WebRTC?

 

Muthu

 

From: tsvwg-bounces@ietf.org = [mailto:tsvwg-bounces@ietf.org] On Behalf Of Jose Saldana
Sent: Thursday, February 16, 2012 9:17 PM
To: tsvwg@ietf.org
Subject: Proposal for tunneling, compressing and multiplexing = flows

 

Hello all.

 

My name is Jose Saldana, from the University of Zaragoza, in Spain. I am new in = this workgroup.

 

Today I have = uploaded a new draft: http:= //datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/:

 

        &nb= sp;       Title           : = Tunneling Compressed Multiplexed Traffic Flows (TCMTF)

        &nb= sp;       Author(s)       : Jose = Saldana

        &nb= sp;       Filename        : draft-saldana-tsvwg-tcmtf-00.txt

        &nb= sp;       Pages           : = 16

        &nb= sp;       Date            : 2012-02-16

 

I am not the sole = author of the draft. In fact, six more people have contributed to build it: Dan Wing = (Cisco), Julian Fernandez-Navajas (Univ. of Zaragoza), Jose Ruiz-Mas (Univ. of Zaragoza), Muthu A. M. Perumal (Cisco), Gonzalo Camarillo (Ericsson) and Michael Ramalho(Cisco).

 

Abstract: This document describes a method to improve the = bandwidth utilization  of network paths that carry multiple streams in = parallel between two endpoints, as in voice trunking.  The method combines standard  protocols that provide compression, multiplexing, and = tunneling over  a network path for the purpose of reducing the bandwidth used = when multiple streams are carried over that path.

 

The main idea is to update TCRTP. This is a = "Best current practice" RFC (http://datatracker.ietf.org/doc/rfc4170 = ) which was developed in Audio/Video Transport working group in 2005-11. = It "describes a method to = improve the bandwidth utilization of RTP streams over network paths that carry = multiple Real-time Transport Protocol (RTP) streams in parallel between two = endpoints, as in voice trunking. The method combines standard protocols that = provide compression, multiplexing, and tunneling over a network path for the = purpose of reducing the bandwidth used when multiple RTP streams are carried over = that path." (from the introduction of RFC4170).

 

The scheme of TCRTP is:

 

   RTP/UDP/IP

      |

      |

    ECRTP (compressing layer). Compresses RTP/UDP/IP = headers

      |

      |

     PPPMux (multiplexing layer). Includes a number of compressed packets = into a bigger one

      |

      |

    L2TP     (tunneling layer). Permits its use = end-to-end

      |

      |

      IP

 

However, there exist many real-time flows that do not use RTP:

 

- = Online "First Person Shooter" (FPS) games use UDP datagrams, and they = are one of the most "real-time" applications nowadays. Some examples: Counter Strike, Halo, Quake, etc.[1].

 

- Online "Massively Multiplayer Online Role = Playing Games" (MMORPG): They use TCP, but can be considered "real-time", since the actions of the players have to be = transmitted very quickly to the server. It should be taken into account that player vs player fights are one of the possible activities of the game. Some examples: World of Warcraft (more = than 10 million subscribers) [2].

 

- = TCP is also getting used for media delivery. For many reasons, such as avoiding = firewalls, the standard IP/ UDP/ RTP protocol stack is substituted in many cases by = IP/ TCP/ HTTP/ FLV [3].

 

- Another interesting scenario is satellite = communication links. Multiplexing small packets into one packet for transmission would improve the efficiency. Satellite links would also find it useful to multiplex small TCP packets into one = packet - this could be especially interesting for compressing TCP = ACKs.

 

 

In our recent research activities, we have adapted TCRTP scheme for its use when the = traffic is not RTP. The idea is to substitute ECRTP by other compression scheme = which can be used for UDP or TCP headers. In 2006, the IETF formed the Robust = Header Compression (ROHC) working group which created specifications for header compression over links for RTP, UDP and TCP.  These specifications = were extended to compress headers over other networks. For most RTP flows, = ROHC is more bandwidth efficient than ECRTP, at the cost of implementation = complexity. It has a special care of context synchronization, defining some states = at the compressor and decompressor. Once the effort for designing ROHC has been conducted, it is worth including it in the compressing and multiplexing standard.

 

In a recent paper in Nov. issue of IEEE = Communications Magazine, it was shown that 30% of bandwidth saving can be achieved for = 8 FPS different games using IPv4. If IPv6 is used, savings can be up to 54% [4]. Another recent study, which is = still under review, has estimated 45% bandwidth saving for World of = Warcraft.

 

After working with other researchers, we have = developed a standard. The possible scheme of the proposal could be this = one:

 

        G.711 = or other payload

        &nbs= p;          |            =           ------------------------------

        &nbs= p;          |

G.711.0 or other payload compression        payload = compression layer

        &nbs= p;          |

        &nbs= p;          |   =             &= nbsp;      ------------------------------

    TCP    = UDP  RTP/UDP

     = |      |      |

      = \     |     /            =            ------------------------------

        = \   |   /

Nothing or ROHC or ECRTP or IPHC           &nb= sp; header compressing layer

        &nbs= p;      |

        &nbs= p;      |            =             &= nbsp; ------------------------------

        &nbs= p;      |

   PPPMUX or other mux protocols          &nbs= p;     multiplexing layer

        &nbs= p;      |

        &nbs= p;      |            =             &= nbsp; ------------------------------

        &nbs= p;      |

        GRE = or L2TP or other           &n= bsp;          tunneling layer

        &nbs= p;      |

       =         |            =             &= nbsp; ------------------------------

       =         IP

 

It should be more "open" than TCRTP. I = the use of different protocols could be "orthogonal": different header compression algorithms could be used, depending on the application and = the scenario; also different multiplexing and tunneling protocols could be included. Finally, another option has been considered: A payload = compression layer.  When the payload is G.711 this layer can runs G.711.0, = a  lossless and stateless compression/decompression of the payload  [I.711].  This operations can be deployed by network elements like   routers/switches, without the endpoints having to = signal it using   RTSP/SDP/SIP, since G.711 has a fixed RTP payload = number.

 

Regarding the scenarios, we have considered some of them:

 

- = A provider of a real-time service (e.g. game or voip) can have an infrastructure = with a number of proxies that can group traffic from different users and send = it to the server.

 

- An Internet caf=E9, where a number (sometimes = big) of players share the same access link. Bandwidth is scarce in that scenario.

 

- = A satellite link, where the bandwidth and the pps have to be = saved.

 

- Desktop or = application sharing where the traffic from the server to the client typically = consists of the delta of screen updates.  Also, the standard for remote desktop sharing emerging for WebRTC in the RTCWEB Working  Group is: {something}/SCTP/UDP (Stream Control Transmission Protocol = [SCTP]).  In this scenario, SCTP/UDP could be used in other cases:  chatting, = file sharing and applications related to WebRTC peers. There could be = hundreds of clients at a site talking to a server located at a datacenter over a = WAN.

 

Thank you very much, and sorry for writing such = a long message,

 

Jose Saldana

University of Zaragoza

 

PS: We have also = written a paper, which will be presented in next ICC conference, in Ottawa in = June. You can read a draft here: http://diec.unizar.es/~jsaldana/personal/widening_scope_draft.pdf

 

______________

 

[1] Ratti, S.; Hariri, B.; Shirmohammadi, S., "A Survey of First-Person Shooter = Gaming Traffic on the Internet," Internet Computing, IEEE , vol.14, no.5, pp.60-69, Sept.-Oct. 2010. URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D= &arnumber=3D5445069&isnumber=3D5562482

 

[2] P. Svoboda, W Karner and M. Rupp, = "Traffic Analysis and Modeling for World of Warcraft," ICC '07. IEEE International Conference on = Communications, pp.1612-1617, 24-28, Jun. 2007. URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D= &arnumber=3D4288941&isnumber=3D4288671

 

[3] G. Marfia and M. Roccetti, "TCP At = Last: Reconsidering TCP's Role for Wireless Entertainment Centers at = Home," IEEE Transactions on Consumer Electronics, Vol. 56, N. 4, Nov. 2010, pp. = 2233-2240. URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D= &arnumber=3D5681095&isnumber=3D5681060

 

[4] J. Saldana, J. Fern=E1ndez-Navajas, J. = Ruiz-Mas, J. I. Aznar, E. Viruete and  L. Casadesus, "First Person Shooters: = Can a Smarter Network Save Bandwidth without Annoying the Players?," IEEE Communications Magazine, Consumer Communications and Networking Series, = vol. 49, no.

11, pp. 190-198, Nov. 2011. URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D= &arnumber=3D6069728&isnumber=3D6069696

 

 

------_=_NextPart_001_01CCEFFC.1E7DDFC1-- From christer.holmberg@ericsson.com Mon Feb 20 12:02: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 B545221F87BC for ; Mon, 20 Feb 2012 12:02:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.004 X-Spam-Level: X-Spam-Status: No, score=-10.004 tagged_above=-999 required=5 tests=[AWL=0.595, 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 O5y-BHr3XjrF for ; Mon, 20 Feb 2012 12:02:08 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id CDCF421F87C7 for ; Mon, 20 Feb 2012 12:02:07 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-7d-4f42a6beae0e Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 61.B4.27041.EB6A24F4; Mon, 20 Feb 2012 21:02:06 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Mon, 20 Feb 2012 21:02:06 +0100 From: Christer Holmberg To: Justin Uberti Date: Mon, 20 Feb 2012 21:02:05 +0100 Thread-Topic: JSEP-02: New offer and answer to previous offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case] Thread-Index: AQHM8AqE+28vByK84kKxG08H/gll9w== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3D31BA37@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-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: [rtcweb] JSEP-02: New offer and answer to previous offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case] 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, 20 Feb 2012 20:02:09 -0000 Hi, A related question regarding resources. Assume the following case: 1. A JS app requests the broswer to generate an offer (o-1), which the JS a= pp sends away to the remote end (e.g. using SIP INVITE). 2. The JS app receives a provisional answer, and sends it to the browser us= ing SDP_PRANSWER (I assume we will keep PRANSWER, but otherwise it could al= so be ANSWER). 3. The JS app requests a new offer (o-2) to be created by the browser. The questions: Q1. When the JS app requests the new offer (o-2), I assume all resources et= c associated with o-1 will be released (unless they are also needed for o-2= , that is). Q2. If the JS app receives an answer for the first offer (o-1), will it sen= d it to the browser, or will it discard it? If if sends it to the browser, = what is the browser expected to do with it? I assume there is a way for the= browser to determine (e.g. using the o- line) that the answer is for the f= irst offer. Q3. Is the JS app allowed to request a new offer in the first place, before= the "final answer" has been provided to the browser (whatever the mechanis= m to inform the browser that an answer is the final one is)? Regards, Christer ________________________________________ From: Justin Uberti [juberti@google.com] Sent: Monday, February 20, 2012 5:12 PM To: Christer Holmberg Cc: Ravindran, Parthasarathi; Hutton, Andrew; Cullen Jennings; rtcweb@ietf.= org; public-webrtc@w3.org Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case Right; if we retain PRANSWER, I think "may have more answers in the future"= should be its meaning, and applications can map things like 18x to PRANSWE= R, if desired. I agree that PRANSWER should not have implicit recvonly semantics, and we s= hould use explicit directional attributes instead. On Mon, Feb 20, 2012 at 7:59 AM, Christer Holmberg > wrote: Hi, We can do it with timers, PRANSWER, or both. I just think the browser at so= me point shall be able to determine that there will be no more answers to a= given offer :) Regards, Christer -----Original Message----- From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] Sent: 20. helmikuuta 2012 13:53 To: Christer Holmberg; Hutton, Andrew; Cullen Jennings Cc: rtcweb@ietf.org; public-webrtc@w3.org Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case Hi Christer, I agree with you for the timer to release the unused offer resource from o= fferer browser if it is really a constraint. This timer helps browser from = badly designed webpage which sends offer but never complete answer. Let us = get more opinion on this. Timer mechanism shall be applicable with multiple SDP_ANSWER and there is n= o need of SDP_PRANSWER. The reason for requesting SDP_PRANSWER removal is t= o simplify O/A FSM in JS. In case SDP_ANSWER before timer expires, setRemo= teDescription returns success with updating answer in browser or else retur= n failure. Please let me know your opinion on the same. Thanks Partha >-----Original Message----- >From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >Sent: Monday, February 20, 2012 4:46 PM >To: Ravindran, Parthasarathi; Hutton, Andrew; Cullen Jennings >Cc: rtcweb@ietf.org; public-webrtc@w3.org >Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case > > >Hi, > >There could always be a mechanism, where the broswer automatically >releases resources, if it hasn't received a SDP_ANSWER within a given >time. > >Regards, > >Christer > > >-----Original Message----- >From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] >Sent: 20. helmikuuta 2012 12:41 >To: Christer Holmberg; Hutton, Andrew; Cullen Jennings >Cc: rtcweb@ietf.org; public-webrtc@w3.org >Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case > >Hi Christer, > >It is obvious fact that mobile devices has limited resource. The >question is whether Mobile devices offer multiple codec during the >initial offer and waiting to release during the final answer for saving >memory resource. Final answer expecting design may have the impact >because the badly designed webpage may hog the system easily by just >sending offer & not mapping with answer and also in the scenario of >answerer reply with multiple codec. > >As part of SRTP discussion, Eric clarifies that Media security (SRTP) >is not an (CPU) performance issue in the endpoint. I could not >understand about ICE issues as ICE is triggered based on the number of >answer apart from the initial ICE procedure for offer. > >Thanks >Partha > >>-----Original Message----- >>From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>Sent: Monday, February 20, 2012 3:39 PM >>To: Ravindran, Parthasarathi; Hutton, Andrew; Cullen Jennings >>Cc: rtcweb@ietf.org; public-webrtc@w3.org >>Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >> >> >>Hi, >> >>Mobile devices (smartphones etc) will often have limited resources, no >>matter whether the app is running as a browser app or a native app. >> >>Also, codec was only one example. A better example is perhaps >>resources related to ICE, media security etc. >> >>Regards, >> >>Christer >> >> >>-----Original Message----- >>From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] >>Sent: 20. helmikuuta 2012 11:55 >>To: Christer Holmberg; Hutton, Andrew; Cullen Jennings >>Cc: rtcweb@ietf.org; public-webrtc@w3.org >>Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >> >>Hi Christer, >> >>Even I had thought through Cullen statement before reply to him in the >>another mail thread. As per your clarification, Each Codec (like g711 >>library, g729 library) will be loaded in the memory in the run-time >>based on offer and released based on the final answer for the memory >>saving. I agree that this mechanism is useful for DSP based VoIP >>endpoints wherein it is possible to load only one codec (or few codec) >>at the same time, mostly only one of the codec (first codec) will be >>loaded based on the answer and send Re-INVITE to indicate the >>committed codec in DSP. My understanding is that the same issue does >>not exists for WebRTC browser running in laptop, desktop and those >>devices will be capable of loading the multiple codec without >>impacting the system performance. Please correct me in case I >>misunderstand the system design here. I'm not very sure about >>Smartphone architecture w.r.t multiple codec handling. >> >>I have asked for 18x with SDP and 2xx without SDP scenario just to >>indicate the complication building up in the JavaScript offer/answer >>FSM because of the (provisional/final) response specific offer/answer >model. >> >>Thanks >>Partha >> >>>-----Original Message----- >>>From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>>Sent: Monday, February 20, 2012 12:51 PM >>>To: Ravindran, Parthasarathi; Hutton, Andrew; Cullen Jennings >>>Cc: rtcweb@ietf.org; public-webrtc@w3.org >>>Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >>> >>> >>>Hi, >>> >>>> IIUC, your proposal is to update JSEP SDP_PRANSWER and SDP_ANSWER >>>> as equivalent to moreComing=3Dtrue/false in ROAP. Also, we need to >>>> consider >>>the scenario like 18x with SDP (SDP_PRANSWER) and 2xx without SDP >>>wherein JS has to take care of SDP_ANSWER even though it does not >>>receive one. IMO, Multiple answer issue is not fully solved in ROAP >>>as well. >>> >>>In that case, I guess the JS app could simply take a previous >>>SDP_PRANSWER, and send it as SDP_ANSWER. >>> >>>> Also, I have the problem in the understanding the strong need for >>>differentiating answer and final answer. Could you please clarify it. >>> >>>I had exactly the same issue, but what Cullen told me last week made >>>me re-think. It's all about resources :) >>> >>>So, take the following example: >>> >>>1. The browser creates an offer, and reservers resrouces for codecs X >>>and Y. >>>2. At some point, the browser receives a PRANSWER, with only codec X. >>>However, the browser still keeps the resources for Y, as a new answer >>>may come. >>>3. At some point, the browser receives another PRANSWER (maybe >>>forking has occured), with only codec Y. However, the browser still >>>keeps the resources for X (again, as a new answer may come). >>>4. At some point, the browser recieves an ANSWER, with only codec X. >>>Now, as this is the last answer, the browser can release the >>>resources for Y. >>> >>>So, the main difference is related to the resources associated with >>>the offer. Once a final answer (ANSWER) has been received, and >>>resources that were reserved for the offer, but are no longer needed, >>>can be released. >>> >>>(Cullen, please correct me if I've missunderstood :) >>> >>>Regards, >>> >>>Christer >>> >>> >>>>-----Original Message----- >>>>From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>>>Sent: Monday, February 20, 2012 12:12 PM >>>>To: Hutton, Andrew; Ravindran, Parthasarathi; Cullen Jennings >>>>Cc: rtcweb@ietf.org; public-webrtc@w3.org >>>>Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >>>> >>>> >>>>Hi, >>>> >>>>In my opinion, even if we do need SDP_PRANSWER (Cullen may have >>>>convinced me that there is a need for it :), I don't think it should >>>>have an implicit "recvonly" meaning. >>>> >>>>PRANSWER or ANSWER, I think we shall use the SDP direction attribute >>>>(or some other explicit elements) to indicate media direction. >>>> >>>>Regards, >>>> >>>>Christer >>>> >>>> >>>> >>>>-----Original Message----- >>>>From: rtcweb-bounces@ietf.org [mailto:r= tcweb-bounces@ietf.org] On >>>>Behalf Of Hutton, Andrew >>>>Sent: 19. helmikuuta 2012 23:26 >>>>To: Ravindran, Parthasarathi; Cullen Jennings >>>>Cc: rtcweb@ietf.org; public-webrtc@w3.org >>>>Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >>>> >>>>Hi, >>>> >>>>Yes absolutely I have come across a number of scenarios in the US >>>>and in Europe where media is needed in the forward direction for >>>>DTMF input after receiving a 18x response and before the 200OK. IF I >>>>remember correctly calling FEDEX was actually one of the real life >>examples. >>>> >>>>Regards >>>>Andy >>>> >>>> >>>>> -----Original Message----- >>>>> From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] >>>>> Sent: 19 February 2012 17:53 >>>>> To: Cullen Jennings; Hutton, Andrew >>>>> Cc: public-webrtc@w3.org; rtcweb@ietf.or= g >>>>> Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >>>>> >>>>> Cullen, >>>>> >>>>> AFAIK, 18x with sendrecv as direction attribute & DTMF (telephony- >>>>> event) is allowed by couple of operators in FEDEX (call center) >>>>> scenario. Andy will be able to double confirm whether he also >>>>> comes across the similar deployment. >>>>> >>>>> Thanks >>>>> Partha >>>>> >>>>> >>>>> >>>>> >-----Original Message----- >>>>> >From: rtcweb-bounces@ietf.org [mailt= o:rtcweb-bounces@ietf.org] On >>>>> Behalf >>>>> >Of Cullen Jennings >>>>> >Sent: Saturday, February 18, 2012 2:29 AM >>>>> >To: Hutton, Andrew >>>>> >Cc: public-webrtc@w3.org; rtcweb@ietf.o= rg >>>>> >Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >>>>> > >>>>> > >>>>> >On Feb 16, 2012, at 1:04 PM, Hutton, Andrew wrote: >>>>> > >>>>> >>> (Also, in the FEDEX case, there could be scenarios where the >>>>> browser >>>>> >>> does need to transit media, if the user is e.g. promted for >>>>> >>> DTMFs, voice commands etc...) >>>>> >>> >>>>> >> >>>>> >> [AndyH] - I agree that media transmission is required at this >>>>> >> stage >>>>> so >>>>> >that the user can navigate through voice prompts (E.g. via DTMF) >>>>> >I thought this was the main requirement from the FEDEX use case. >>>>> > >>>>> >that's not my understanding. My understanding was it was one way >>>>> >media until the final response in the early media case. And the >>>>> >IVR sends >>>>> the >>>>> >first prompt as ringtone but cuts over before two way media (IE >>>>> >DTMF) >>>>> is >>>>> >needed. The whole point of this hack is to cut the time the IVR >>>>> >gets billed for but the SP is not going to provide two way media >>>>> >before billing starts. >>>>> > >>>>> > >>>>> >_______________________________________________ >>>>> >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 christer.holmberg@ericsson.com Mon Feb 20 12:05: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 880C221F864E for ; Mon, 20 Feb 2012 12:05:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.017 X-Spam-Level: X-Spam-Status: No, score=-10.017 tagged_above=-999 required=5 tests=[AWL=0.582, 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 VbkqCbZfHSLp for ; Mon, 20 Feb 2012 12:05:49 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id DC7B621F8670 for ; Mon, 20 Feb 2012 12:05:48 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-e0-4f42a79bf2d0 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id E6.E4.27041.B97A24F4; Mon, 20 Feb 2012 21:05:48 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Mon, 20 Feb 2012 21:05:47 +0100 From: Christer Holmberg To: Justin Uberti Date: Mon, 20 Feb 2012 21:04:50 +0100 Thread-Topic: [rtcweb] JSEP-02: New offer and answer to previous offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case] Thread-Index: AQHM8AqE+28vByK84kKxG08H/gll95ZGNbjU Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3D31BA39@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C3D31BA37@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3D31BA37@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-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case] 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, 20 Feb 2012 20:05:51 -0000 Just a clarification regarding Q1. The browser will of course keep the reso= urces associated with o-1 until the new offer has been accepted by the remo= te party, and can be taken into use. ________________________________________ From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] On Behalf Of Christ= er Holmberg [christer.holmberg@ericsson.com] Sent: Monday, February 20, 2012 10:02 PM To: Justin Uberti Cc: rtcweb@ietf.org; public-webrtc@w3.org Subject: [rtcweb] JSEP-02: New offer and answer to previous offer [was: JSE= P-02: SDP_PRANSWER and FEDEX use-case] Hi, A related question regarding resources. Assume the following case: 1. A JS app requests the broswer to generate an offer (o-1), which the JS a= pp sends away to the remote end (e.g. using SIP INVITE). 2. The JS app receives a provisional answer, and sends it to the browser us= ing SDP_PRANSWER (I assume we will keep PRANSWER, but otherwise it could al= so be ANSWER). 3. The JS app requests a new offer (o-2) to be created by the browser. The questions: Q1. When the JS app requests the new offer (o-2), I assume all resources et= c associated with o-1 will be released (unless they are also needed for o-2= , that is). Q2. If the JS app receives an answer for the first offer (o-1), will it sen= d it to the browser, or will it discard it? If if sends it to the browser, = what is the browser expected to do with it? I assume there is a way for the= browser to determine (e.g. using the o- line) that the answer is for the f= irst offer. Q3. Is the JS app allowed to request a new offer in the first place, before= the "final answer" has been provided to the browser (whatever the mechanis= m to inform the browser that an answer is the final one is)? Regards, Christer ________________________________________ From: Justin Uberti [juberti@google.com] Sent: Monday, February 20, 2012 5:12 PM To: Christer Holmberg Cc: Ravindran, Parthasarathi; Hutton, Andrew; Cullen Jennings; rtcweb@ietf.= org; public-webrtc@w3.org Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case Right; if we retain PRANSWER, I think "may have more answers in the future"= should be its meaning, and applications can map things like 18x to PRANSWE= R, if desired. I agree that PRANSWER should not have implicit recvonly semantics, and we s= hould use explicit directional attributes instead. On Mon, Feb 20, 2012 at 7:59 AM, Christer Holmberg > wrote: Hi, We can do it with timers, PRANSWER, or both. I just think the browser at so= me point shall be able to determine that there will be no more answers to a= given offer :) Regards, Christer -----Original Message----- From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] Sent: 20. helmikuuta 2012 13:53 To: Christer Holmberg; Hutton, Andrew; Cullen Jennings Cc: rtcweb@ietf.org; public-webrtc@w3.org Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case Hi Christer, I agree with you for the timer to release the unused offer resource from o= fferer browser if it is really a constraint. This timer helps browser from = badly designed webpage which sends offer but never complete answer. Let us = get more opinion on this. Timer mechanism shall be applicable with multiple SDP_ANSWER and there is n= o need of SDP_PRANSWER. The reason for requesting SDP_PRANSWER removal is t= o simplify O/A FSM in JS. In case SDP_ANSWER before timer expires, setRemo= teDescription returns success with updating answer in browser or else retur= n failure. Please let me know your opinion on the same. Thanks Partha >-----Original Message----- >From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >Sent: Monday, February 20, 2012 4:46 PM >To: Ravindran, Parthasarathi; Hutton, Andrew; Cullen Jennings >Cc: rtcweb@ietf.org; public-webrtc@w3.org >Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case > > >Hi, > >There could always be a mechanism, where the broswer automatically >releases resources, if it hasn't received a SDP_ANSWER within a given >time. > >Regards, > >Christer > > >-----Original Message----- >From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] >Sent: 20. helmikuuta 2012 12:41 >To: Christer Holmberg; Hutton, Andrew; Cullen Jennings >Cc: rtcweb@ietf.org; public-webrtc@w3.org >Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case > >Hi Christer, > >It is obvious fact that mobile devices has limited resource. The >question is whether Mobile devices offer multiple codec during the >initial offer and waiting to release during the final answer for saving >memory resource. Final answer expecting design may have the impact >because the badly designed webpage may hog the system easily by just >sending offer & not mapping with answer and also in the scenario of >answerer reply with multiple codec. > >As part of SRTP discussion, Eric clarifies that Media security (SRTP) >is not an (CPU) performance issue in the endpoint. I could not >understand about ICE issues as ICE is triggered based on the number of >answer apart from the initial ICE procedure for offer. > >Thanks >Partha > >>-----Original Message----- >>From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>Sent: Monday, February 20, 2012 3:39 PM >>To: Ravindran, Parthasarathi; Hutton, Andrew; Cullen Jennings >>Cc: rtcweb@ietf.org; public-webrtc@w3.org >>Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >> >> >>Hi, >> >>Mobile devices (smartphones etc) will often have limited resources, no >>matter whether the app is running as a browser app or a native app. >> >>Also, codec was only one example. A better example is perhaps >>resources related to ICE, media security etc. >> >>Regards, >> >>Christer >> >> >>-----Original Message----- >>From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] >>Sent: 20. helmikuuta 2012 11:55 >>To: Christer Holmberg; Hutton, Andrew; Cullen Jennings >>Cc: rtcweb@ietf.org; public-webrtc@w3.org >>Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >> >>Hi Christer, >> >>Even I had thought through Cullen statement before reply to him in the >>another mail thread. As per your clarification, Each Codec (like g711 >>library, g729 library) will be loaded in the memory in the run-time >>based on offer and released based on the final answer for the memory >>saving. I agree that this mechanism is useful for DSP based VoIP >>endpoints wherein it is possible to load only one codec (or few codec) >>at the same time, mostly only one of the codec (first codec) will be >>loaded based on the answer and send Re-INVITE to indicate the >>committed codec in DSP. My understanding is that the same issue does >>not exists for WebRTC browser running in laptop, desktop and those >>devices will be capable of loading the multiple codec without >>impacting the system performance. Please correct me in case I >>misunderstand the system design here. I'm not very sure about >>Smartphone architecture w.r.t multiple codec handling. >> >>I have asked for 18x with SDP and 2xx without SDP scenario just to >>indicate the complication building up in the JavaScript offer/answer >>FSM because of the (provisional/final) response specific offer/answer >model. >> >>Thanks >>Partha >> >>>-----Original Message----- >>>From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>>Sent: Monday, February 20, 2012 12:51 PM >>>To: Ravindran, Parthasarathi; Hutton, Andrew; Cullen Jennings >>>Cc: rtcweb@ietf.org; public-webrtc@w3.org >>>Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >>> >>> >>>Hi, >>> >>>> IIUC, your proposal is to update JSEP SDP_PRANSWER and SDP_ANSWER >>>> as equivalent to moreComing=3Dtrue/false in ROAP. Also, we need to >>>> consider >>>the scenario like 18x with SDP (SDP_PRANSWER) and 2xx without SDP >>>wherein JS has to take care of SDP_ANSWER even though it does not >>>receive one. IMO, Multiple answer issue is not fully solved in ROAP >>>as well. >>> >>>In that case, I guess the JS app could simply take a previous >>>SDP_PRANSWER, and send it as SDP_ANSWER. >>> >>>> Also, I have the problem in the understanding the strong need for >>>differentiating answer and final answer. Could you please clarify it. >>> >>>I had exactly the same issue, but what Cullen told me last week made >>>me re-think. It's all about resources :) >>> >>>So, take the following example: >>> >>>1. The browser creates an offer, and reservers resrouces for codecs X >>>and Y. >>>2. At some point, the browser receives a PRANSWER, with only codec X. >>>However, the browser still keeps the resources for Y, as a new answer >>>may come. >>>3. At some point, the browser receives another PRANSWER (maybe >>>forking has occured), with only codec Y. However, the browser still >>>keeps the resources for X (again, as a new answer may come). >>>4. At some point, the browser recieves an ANSWER, with only codec X. >>>Now, as this is the last answer, the browser can release the >>>resources for Y. >>> >>>So, the main difference is related to the resources associated with >>>the offer. Once a final answer (ANSWER) has been received, and >>>resources that were reserved for the offer, but are no longer needed, >>>can be released. >>> >>>(Cullen, please correct me if I've missunderstood :) >>> >>>Regards, >>> >>>Christer >>> >>> >>>>-----Original Message----- >>>>From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>>>Sent: Monday, February 20, 2012 12:12 PM >>>>To: Hutton, Andrew; Ravindran, Parthasarathi; Cullen Jennings >>>>Cc: rtcweb@ietf.org; public-webrtc@w3.org >>>>Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >>>> >>>> >>>>Hi, >>>> >>>>In my opinion, even if we do need SDP_PRANSWER (Cullen may have >>>>convinced me that there is a need for it :), I don't think it should >>>>have an implicit "recvonly" meaning. >>>> >>>>PRANSWER or ANSWER, I think we shall use the SDP direction attribute >>>>(or some other explicit elements) to indicate media direction. >>>> >>>>Regards, >>>> >>>>Christer >>>> >>>> >>>> >>>>-----Original Message----- >>>>From: rtcweb-bounces@ietf.org [mailto:r= tcweb-bounces@ietf.org] On >>>>Behalf Of Hutton, Andrew >>>>Sent: 19. helmikuuta 2012 23:26 >>>>To: Ravindran, Parthasarathi; Cullen Jennings >>>>Cc: rtcweb@ietf.org; public-webrtc@w3.org >>>>Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >>>> >>>>Hi, >>>> >>>>Yes absolutely I have come across a number of scenarios in the US >>>>and in Europe where media is needed in the forward direction for >>>>DTMF input after receiving a 18x response and before the 200OK. IF I >>>>remember correctly calling FEDEX was actually one of the real life >>examples. >>>> >>>>Regards >>>>Andy >>>> >>>> >>>>> -----Original Message----- >>>>> From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] >>>>> Sent: 19 February 2012 17:53 >>>>> To: Cullen Jennings; Hutton, Andrew >>>>> Cc: public-webrtc@w3.org; rtcweb@ietf.or= g >>>>> Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >>>>> >>>>> Cullen, >>>>> >>>>> AFAIK, 18x with sendrecv as direction attribute & DTMF (telephony- >>>>> event) is allowed by couple of operators in FEDEX (call center) >>>>> scenario. Andy will be able to double confirm whether he also >>>>> comes across the similar deployment. >>>>> >>>>> Thanks >>>>> Partha >>>>> >>>>> >>>>> >>>>> >-----Original Message----- >>>>> >From: rtcweb-bounces@ietf.org [mailt= o:rtcweb-bounces@ietf.org] On >>>>> Behalf >>>>> >Of Cullen Jennings >>>>> >Sent: Saturday, February 18, 2012 2:29 AM >>>>> >To: Hutton, Andrew >>>>> >Cc: public-webrtc@w3.org; rtcweb@ietf.o= rg >>>>> >Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case >>>>> > >>>>> > >>>>> >On Feb 16, 2012, at 1:04 PM, Hutton, Andrew wrote: >>>>> > >>>>> >>> (Also, in the FEDEX case, there could be scenarios where the >>>>> browser >>>>> >>> does need to transit media, if the user is e.g. promted for >>>>> >>> DTMFs, voice commands etc...) >>>>> >>> >>>>> >> >>>>> >> [AndyH] - I agree that media transmission is required at this >>>>> >> stage >>>>> so >>>>> >that the user can navigate through voice prompts (E.g. via DTMF) >>>>> >I thought this was the main requirement from the FEDEX use case. >>>>> > >>>>> >that's not my understanding. My understanding was it was one way >>>>> >media until the final response in the early media case. And the >>>>> >IVR sends >>>>> the >>>>> >first prompt as ringtone but cuts over before two way media (IE >>>>> >DTMF) >>>>> is >>>>> >needed. The whole point of this hack is to cut the time the IVR >>>>> >gets billed for but the SP is not going to provide two way media >>>>> >before billing starts. >>>>> > >>>>> > >>>>> >_______________________________________________ >>>>> >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 ibc@aliax.net Mon Feb 20 12:14: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 ACF6821F85C2 for ; Mon, 20 Feb 2012 12:14:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[AWL=0.057, 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 sW4v3FYlxtsW for ; Mon, 20 Feb 2012 12:14:19 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id E74B521F85A2 for ; Mon, 20 Feb 2012 12:14:18 -0800 (PST) Received: by vcbfk14 with SMTP id fk14so4367780vcb.31 for ; Mon, 20 Feb 2012 12:14:18 -0800 (PST) Received-SPF: pass (google.com: domain of ibc@aliax.net designates 10.52.95.37 as permitted sender) client-ip=10.52.95.37; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ibc@aliax.net designates 10.52.95.37 as permitted sender) smtp.mail=ibc@aliax.net Received: from mr.google.com ([10.52.95.37]) by 10.52.95.37 with SMTP id dh5mr10444094vdb.88.1329768858405 (num_hops = 1); Mon, 20 Feb 2012 12:14:18 -0800 (PST) Received: by 10.52.95.37 with SMTP id dh5mr8395690vdb.88.1329768858239; Mon, 20 Feb 2012 12:14:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.203.2 with HTTP; Mon, 20 Feb 2012 12:13:58 -0800 (PST) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3D31BA37@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C3D31BA37@ESESSCMS0356.eemea.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 20 Feb 2012 21:13:58 +0100 Message-ID: To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQn1XoK4lTr7N7vkhkc7WuXlDNRt3ZFUOz2GUGu9Ti9drUgcLan5w7x6nR3l4aI4UmQAMvQL Cc: "public-webrtc@w3.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case] 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, 20 Feb 2012 20:14:20 -0000 2012/2/20 Christer Holmberg : > Q1. When the JS app requests the new offer (o-2), I assume all resources = etc associated with o-1 will be released (unless they are also needed for o= -2, that is). Does it mean that the browser is just capable of having *one* multimedia session at the same time? Well, in SIP world this typically means putting on-hold the previous call so, indeed, resources would be released. But, why couldn't the browser send a just-audio offer somewhere and a just-video offer to other destination at the same time? --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Mon Feb 20 12:19:03 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 21B7421F86D1 for ; Mon, 20 Feb 2012 12:19:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.879 X-Spam-Level: X-Spam-Status: No, score=-9.879 tagged_above=-999 required=5 tests=[AWL=0.420, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2YlbG-cK4P4 for ; Mon, 20 Feb 2012 12:19:02 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 28E6A21F8693 for ; Mon, 20 Feb 2012 12:19:01 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-00-4f42aab4ef02 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id DA.42.01970.4BAA24F4; Mon, 20 Feb 2012 21:19:01 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Mon, 20 Feb 2012 21:19:00 +0100 From: Christer Holmberg To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Date: Mon, 20 Feb 2012 21:14:59 +0100 Thread-Topic: [rtcweb] JSEP-02: New offer and answer to previous offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case] Thread-Index: AczwDDn8D7e6okPdSsG8GmzfbJY7pgAABhMB Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3D31BA3A@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C3D31BA37@ESESSCMS0356.eemea.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "public-webrtc@w3.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case] 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, 20 Feb 2012 20:19:03 -0000 Hi, Just to clarify: the new offer is for the same "session" as the previous of= fer, and is supposed to replace the previous offer. The browser can of course send a just-audio offer somewhere, and a just-vid= eo offer somewhere else, but would those even be associated with the same P= eerConnection? I thought we wanted only one offer/answer, which is the reas= on it has been suggested e.g. not to support paralell forking in the browse= r. Regards, Christer ________________________________________ From: I=F1aki Baz Castillo [ibc@aliax.net] Sent: Monday, February 20, 2012 10:13 PM To: Christer Holmberg Cc: Justin Uberti; rtcweb@ietf.org; public-webrtc@w3.org Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous offer [was:= JSEP-02: SDP_PRANSWER and FEDEX use-case] 2012/2/20 Christer Holmberg : > Q1. When the JS app requests the new offer (o-2), I assume all resources = etc associated with o-1 will be released (unless they are also needed for o= -2, that is). Does it mean that the browser is just capable of having *one* multimedia session at the same time? Well, in SIP world this typically means putting on-hold the previous call so, indeed, resources would be released. But, why couldn't the browser send a just-audio offer somewhere and a just-video offer to other destination at the same time? -- I=F1aki Baz Castillo From roman@telurix.com Mon Feb 20 12: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 570CA21F8546 for ; Mon, 20 Feb 2012 12:31:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.85 X-Spam-Level: X-Spam-Status: No, score=-2.85 tagged_above=-999 required=5 tests=[AWL=0.126, 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 P7IoRnxfCyM0 for ; Mon, 20 Feb 2012 12:31:27 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9E30A21F8526 for ; Mon, 20 Feb 2012 12:31:27 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so6882733pbc.31 for ; Mon, 20 Feb 2012 12:31:27 -0800 (PST) Received-SPF: pass (google.com: domain of roman@telurix.com designates 10.68.223.199 as permitted sender) client-ip=10.68.223.199; Authentication-Results: mr.google.com; spf=pass (google.com: domain of roman@telurix.com designates 10.68.223.199 as permitted sender) smtp.mail=roman@telurix.com Received: from mr.google.com ([10.68.223.199]) by 10.68.223.199 with SMTP id qw7mr66354583pbc.79.1329769887520 (num_hops = 1); Mon, 20 Feb 2012 12:31:27 -0800 (PST) Received: by 10.68.223.199 with SMTP id qw7mr54715788pbc.79.1329769887459; Mon, 20 Feb 2012 12:31:27 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id i1sm14006810pbo.76.2012.02.20.12.31.26 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 20 Feb 2012 12:31:26 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so6882705pbc.31 for ; Mon, 20 Feb 2012 12:31:25 -0800 (PST) Received-SPF: pass (google.com: domain of roman@telurix.com designates 10.68.204.7 as permitted sender) client-ip=10.68.204.7; Received: from mr.google.com ([10.68.204.7]) by 10.68.204.7 with SMTP id ku7mr66523416pbc.45.1329769885682 (num_hops = 1); Mon, 20 Feb 2012 12:31:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.204.7 with SMTP id ku7mr54878545pbc.45.1329769885649; Mon, 20 Feb 2012 12:31:25 -0800 (PST) Received: by 10.68.130.132 with HTTP; Mon, 20 Feb 2012 12:31:25 -0800 (PST) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3D31BA3A@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C3D31BA37@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C3D31BA3A@ESESSCMS0356.eemea.ericsson.se> Date: Mon, 20 Feb 2012 15:31:25 -0500 Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=047d7b10d11baaca8a04b96b2d64 X-Gm-Message-State: ALoCoQm1bjtolmBqe1G/IvNYN2B8MZ0+glApPduwEWGP/39ER5wiWUeS5RpIzbWNf6I7tkuV+EFz Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case] 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, 20 Feb 2012 20:31:28 -0000 --047d7b10d11baaca8a04b96b2d64 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Not to beat this horse to death, but why is it "suggested not to have parallel forking"? WebRTC intorduces additional restrictions on RTP stream (remote media sources and SSRCs are known in advance) that make parallel forking implementation trivial. Only thing that is missing is some way to clone the PeerConnection in the API. _____________ Roman Shpount On Mon, Feb 20, 2012 at 3:14 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > > Hi, > > Just to clarify: the new offer is for the same "session" as the previous > offer, and is supposed to replace the previous offer. > > The browser can of course send a just-audio offer somewhere, and a > just-video offer somewhere else, but would those even be associated with > the same PeerConnection? I thought we wanted only one offer/answer, which > is the reason it has been suggested e.g. not to support paralell forking = in > the browser. > > Regards, > > Christer > ________________________________________ > From: I=F1aki Baz Castillo [ibc@aliax.net] > Sent: Monday, February 20, 2012 10:13 PM > To: Christer Holmberg > Cc: Justin Uberti; rtcweb@ietf.org; public-webrtc@w3.org > Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous offer > [was: JSEP-02: SDP_PRANSWER and FEDEX use-case] > > 2012/2/20 Christer Holmberg : > > Q1. When the JS app requests the new offer (o-2), I assume all resource= s > etc associated with o-1 will be released (unless they are also needed for > o-2, that is). > > Does it mean that the browser is just capable of having *one* > multimedia session at the same time? Well, in SIP world this typically > means putting on-hold the previous call so, indeed, resources would be > released. > > But, why couldn't the browser send a just-audio offer somewhere and a > just-video offer to other destination at the same time? > > -- > I=F1aki Baz Castillo > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --047d7b10d11baaca8a04b96b2d64 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Not to beat this horse to death, but why is it "suggested not to have = parallel forking"? WebRTC intorduces additional restrictions on RTP st= ream (remote media sources and SSRCs are known in advance) that make parall= el forking implementation trivial. Only thing that is missing is some way t= o clone the PeerConnection in the API.
_____________
Roman Shpount


On Mon, Feb 20, 2012 at 3:14 PM, Christe= r Holmberg <christer.holmberg@ericsson.com> wrote:

Hi,

Just to clarify: the new offer is for the same "session" as the p= revious offer, and is supposed to replace the previous offer.

The browser can of course send a just-audio offer somewhere, and a just-vid= eo offer somewhere else, but would those even be associated with the same P= eerConnection? I thought we wanted only one offer/answer, which is the reas= on it has been suggested e.g. not to support paralell forking in the browse= r.

Regards,

Christer
________________________________________
From: I=F1aki Baz Castillo [ibc@aliax.net<= /a>]
Sent: Monday, February 20, 2012 10:13 PM
To: Christer Holmberg
Cc: Justin Uberti; rtcweb@ietf.org; = public-webrtc@w3.org
Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous offer [was:= JSEP-02: SDP_PRANSWER and FEDEX use-case]

2012/2/20 Christer Holmberg <christer.holmberg@ericsson.com>:
> Q1. When the JS app requests the new offer (o-2), I assume all resourc= es etc associated with o-1 will be released (unless they are also needed fo= r o-2, that is).

Does it mean that the browser is just capable of having *one*
multimedia session at the same time? Well, in SIP world this typically
means putting on-hold the previous call so, indeed, resources would be
released.

But, why couldn't the browser send a just-audio offer somewhere and a just-video offer to other destination at the same time?

--
I=F1aki Baz Castillo
<ibc@aliax.net>
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--047d7b10d11baaca8a04b96b2d64-- From roman@telurix.com Mon Feb 20 12:37: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 1954421F85B7 for ; Mon, 20 Feb 2012 12:37:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.854 X-Spam-Level: X-Spam-Status: No, score=-2.854 tagged_above=-999 required=5 tests=[AWL=0.122, 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 eB1mdjAqS-gP for ; Mon, 20 Feb 2012 12:37:49 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0D221F8569 for ; Mon, 20 Feb 2012 12:37:49 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so6887368pbc.31 for ; Mon, 20 Feb 2012 12:37:49 -0800 (PST) Received-SPF: pass (google.com: domain of roman@telurix.com designates 10.68.227.36 as permitted sender) client-ip=10.68.227.36; Authentication-Results: mr.google.com; spf=pass (google.com: domain of roman@telurix.com designates 10.68.227.36 as permitted sender) smtp.mail=roman@telurix.com Received: from mr.google.com ([10.68.227.36]) by 10.68.227.36 with SMTP id rx4mr59089171pbc.165.1329770269409 (num_hops = 1); Mon, 20 Feb 2012 12:37:49 -0800 (PST) Received: by 10.68.227.36 with SMTP id rx4mr49190964pbc.165.1329770269290; Mon, 20 Feb 2012 12:37:49 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id q3sm14015667pbc.63.2012.02.20.12.37.47 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 20 Feb 2012 12:37:48 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so6887331pbc.31 for ; Mon, 20 Feb 2012 12:37:47 -0800 (PST) Received-SPF: pass (google.com: domain of roman@telurix.com designates 10.68.208.196 as permitted sender) client-ip=10.68.208.196; Received: from mr.google.com ([10.68.208.196]) by 10.68.208.196 with SMTP id mg4mr67367996pbc.108.1329770267214 (num_hops = 1); Mon, 20 Feb 2012 12:37:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.208.196 with SMTP id mg4mr55598964pbc.108.1329770267192; Mon, 20 Feb 2012 12:37:47 -0800 (PST) Received: by 10.68.130.132 with HTTP; Mon, 20 Feb 2012 12:37:47 -0800 (PST) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3D8C630B@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C3D87E060@ESESSCMS0356.eemea.ericsson.se> <3CBDF06F-F52D-4C09-A78F-1A0D8479572A@iii.ca> <7F2072F1E0DE894DA4B517B93C6A05852C3D87E58F@ESESSCMS0356.eemea.ericsson.se> <101C6067BEC68246B0C3F6843BCCC1E31202EDA663@MCHP058A.global-ad.net> <15CD1ECE-6BDD-4EE0-AA5B-EF40616578CD@iii.ca> <387F9047F55E8C42850AD6B3A7A03C6C0E040A1D@inba-mail01.sonusnet.com> <101C6067BEC68246B0C3F6843BCCC1E312942242CD@MCHP058A.global-ad.net> <7F2072F1E0DE894DA4B517B93C6A05852C3D8C60E1@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E040C04@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C3D8C6134@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E040C6D@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C3D8C630B@ESESSCMS0356.eemea.ericsson.se> Date: Mon, 20 Feb 2012 15:37:47 -0500 Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=14dae9c09a9e68ada004b96b4474 X-Gm-Message-State: ALoCoQlMBg+0e+fZR5fhxMmA4p4xjukdIaSJPTVvCnrj4vEzPtqogD/pW5apmzABK20Cjp41ZNpl Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case 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, 20 Feb 2012 20:37:51 -0000 --14dae9c09a9e68ada004b96b4474 Content-Type: text/plain; charset=ISO-8859-1 Actually codecs are a fairly bad example, since end point should be ready to receive media encoded using any codec present in the offer. The fact that one of the codecs was not present in the answer does not mean that remote party is not planning to send media using this codec. In any case, there is no real overhead due to codec instance since new instance can be created when a first RTP packet with particular payload is received (and closed when RTP packets with a particular payload have not been received for some period of time). The only resource that I know that makes sense to conserve are TURN allocated remote ports. I would be curious to know if there is anything else. _____________ Roman Shpount On Mon, Feb 20, 2012 at 5:08 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > > Hi, > > Mobile devices (smartphones etc) will often have limited resources, no > matter whether the app is running as a browser app or a native app. > > Also, codec was only one example. A better example is perhaps resources > related to ICE, media security etc. > > Regards, > > Christer > > > -----Original Message----- > From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] > Sent: 20. helmikuuta 2012 11:55 > To: Christer Holmberg; Hutton, Andrew; Cullen Jennings > Cc: rtcweb@ietf.org; public-webrtc@w3.org > Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case > > Hi Christer, > > Even I had thought through Cullen statement before reply to him in the > another mail thread. As per your clarification, Each Codec (like g711 > library, g729 library) will be loaded in the memory in the run-time based > on offer and released based on the final answer for the memory saving. I > agree that this mechanism is useful for DSP based VoIP endpoints wherein it > is possible to load only one codec (or few codec) at the same time, mostly > only one of the codec (first codec) will be loaded based on the answer and > send Re-INVITE to indicate the committed codec in DSP. My understanding is > that the same issue does not exists for WebRTC browser running in laptop, > desktop and those devices will be capable of loading the multiple codec > without impacting the system performance. Please correct me in case I > misunderstand the system design here. I'm not very sure about Smartphone > architecture w.r.t multiple codec handling. > > I have asked for 18x with SDP and 2xx without SDP scenario just to > indicate the complication building up in the JavaScript offer/answer FSM > because of the (provisional/final) response specific offer/answer model. > > Thanks > Partha > > >-----Original Message----- > >From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > >Sent: Monday, February 20, 2012 12:51 PM > >To: Ravindran, Parthasarathi; Hutton, Andrew; Cullen Jennings > >Cc: rtcweb@ietf.org; public-webrtc@w3.org > >Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case > > > > > >Hi, > > > >> IIUC, your proposal is to update JSEP SDP_PRANSWER and SDP_ANSWER as > >> equivalent to moreComing=true/false in ROAP. Also, we need to > >> consider > >the scenario like 18x with SDP (SDP_PRANSWER) and 2xx without SDP > >wherein JS has to take care of SDP_ANSWER even though it does not > >receive one. IMO, Multiple answer issue is not fully solved in ROAP as > >well. > > > >In that case, I guess the JS app could simply take a previous > >SDP_PRANSWER, and send it as SDP_ANSWER. > > > >> Also, I have the problem in the understanding the strong need for > >differentiating answer and final answer. Could you please clarify it. > > > >I had exactly the same issue, but what Cullen told me last week made me > >re-think. It's all about resources :) > > > >So, take the following example: > > > >1. The browser creates an offer, and reservers resrouces for codecs X > >and Y. > >2. At some point, the browser receives a PRANSWER, with only codec X. > >However, the browser still keeps the resources for Y, as a new answer > >may come. > >3. At some point, the browser receives another PRANSWER (maybe forking > >has occured), with only codec Y. However, the browser still keeps the > >resources for X (again, as a new answer may come). > >4. At some point, the browser recieves an ANSWER, with only codec X. > >Now, as this is the last answer, the browser can release the resources > >for Y. > > > >So, the main difference is related to the resources associated with the > >offer. Once a final answer (ANSWER) has been received, and resources > >that were reserved for the offer, but are no longer needed, can be > >released. > > > >(Cullen, please correct me if I've missunderstood :) > > > >Regards, > > > >Christer > > > > > >>-----Original Message----- > >>From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > >>Sent: Monday, February 20, 2012 12:12 PM > >>To: Hutton, Andrew; Ravindran, Parthasarathi; Cullen Jennings > >>Cc: rtcweb@ietf.org; public-webrtc@w3.org > >>Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case > >> > >> > >>Hi, > >> > >>In my opinion, even if we do need SDP_PRANSWER (Cullen may have > >>convinced me that there is a need for it :), I don't think it should > >>have an implicit "recvonly" meaning. > >> > >>PRANSWER or ANSWER, I think we shall use the SDP direction attribute > >>(or some other explicit elements) to indicate media direction. > >> > >>Regards, > >> > >>Christer > >> > >> > >> > >>-----Original Message----- > >>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > >>Behalf Of Hutton, Andrew > >>Sent: 19. helmikuuta 2012 23:26 > >>To: Ravindran, Parthasarathi; Cullen Jennings > >>Cc: rtcweb@ietf.org; public-webrtc@w3.org > >>Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case > >> > >>Hi, > >> > >>Yes absolutely I have come across a number of scenarios in the US and > >>in Europe where media is needed in the forward direction for DTMF > >>input after receiving a 18x response and before the 200OK. IF I > >>remember correctly calling FEDEX was actually one of the real life > examples. > >> > >>Regards > >>Andy > >> > >> > >>> -----Original Message----- > >>> From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] > >>> Sent: 19 February 2012 17:53 > >>> To: Cullen Jennings; Hutton, Andrew > >>> Cc: public-webrtc@w3.org; rtcweb@ietf.org > >>> Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case > >>> > >>> Cullen, > >>> > >>> AFAIK, 18x with sendrecv as direction attribute & DTMF (telephony- > >>> event) is allowed by couple of operators in FEDEX (call center) > >>> scenario. Andy will be able to double confirm whether he also comes > >>> across the similar deployment. > >>> > >>> Thanks > >>> Partha > >>> > >>> > >>> > >>> >-----Original Message----- > >>> >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > >>> Behalf > >>> >Of Cullen Jennings > >>> >Sent: Saturday, February 18, 2012 2:29 AM > >>> >To: Hutton, Andrew > >>> >Cc: public-webrtc@w3.org; rtcweb@ietf.org > >>> >Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case > >>> > > >>> > > >>> >On Feb 16, 2012, at 1:04 PM, Hutton, Andrew wrote: > >>> > > >>> >>> (Also, in the FEDEX case, there could be scenarios where the > >>> browser > >>> >>> does need to transit media, if the user is e.g. promted for > >>> >>> DTMFs, voice commands etc...) > >>> >>> > >>> >> > >>> >> [AndyH] - I agree that media transmission is required at this > >>> >> stage > >>> so > >>> >that the user can navigate through voice prompts (E.g. via DTMF) I > >>> >thought this was the main requirement from the FEDEX use case. > >>> > > >>> >that's not my understanding. My understanding was it was one way > >>> >media until the final response in the early media case. And the IVR > >>> >sends > >>> the > >>> >first prompt as ringtone but cuts over before two way media (IE > >>> >DTMF) > >>> is > >>> >needed. The whole point of this hack is to cut the time the IVR > >>> >gets billed for but the SP is not going to provide two way media > >>> >before billing starts. > >>> > > >>> > > >>> >_______________________________________________ > >>> >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 > --14dae9c09a9e68ada004b96b4474 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Actually codecs are a fairly bad example, since end point should be ready t= o receive media=A0 encoded using any codec present in the offer. The fact t= hat one of the codecs was not present in the answer does not mean that remo= te party is not planning to send media using this codec. In any case, there= is no real overhead due to codec instance since new instance can be create= d when a first RTP packet with particular payload is received (and closed w= hen RTP packets with a particular payload have not been received for some p= eriod of time).

The only resource that I know that makes sense to conserve are TURN all= ocated remote ports. I would be curious to know if there is anything else.<= br clear=3D"all">_____________
Roman Shpount


On Mon, Feb 20, 2012 at 5:08 AM, Christe= r Holmberg <christer.holmberg@ericsson.com> wrote:

Hi,

Mobile devices (smartphones etc) will often have limited resources, no matt= er whether the app is running as a browser app or a native app.

Also, codec was only one example. A better example is perhaps resources rel= ated to ICE, media security etc.

Regards,

Christer


-----Original Message-----
From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com]
Sent: 20. helmikuuta 2012 11:55
To: Christer Holmberg; Hutton, Andrew; Cullen Jennings
Cc: rtcweb@ietf.org; public-webrtc@w3.org
Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case

Hi Christer,

Even I had thought through Cullen statement before reply to him in the anot= her mail thread. As per your clarification, Each Codec (like g711 library, = g729 library) will be loaded in the memory in the run-time based on offer a= nd released based on the final answer for the memory saving. I agree that t= his mechanism is useful for DSP based VoIP endpoints wherein it is possible= to load only one codec (or few codec) at the same time, mostly only one of= the codec (first codec) will be loaded based on the answer and send Re-INV= ITE to indicate the committed codec in DSP. My understanding is that the sa= me issue does not exists for WebRTC browser running in laptop, desktop and = those devices will be capable of loading the multiple codec without impacti= ng the system performance. Please correct me in case I misunderstand the sy= stem design here. I'm not very sure about Smartphone architecture w.r.t= multiple codec handling.

I have asked for 18x with SDP and 2xx without SDP scenario just to indicate= the complication building up in the JavaScript offer/answer FSM because of= the (provisional/final) response specific offer/answer model.

Thanks
Partha

>-----Original Message-----
>From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
>Sent: Monday, February 20, 2012 12:51 PM
>To: Ravindran, Parthasarathi; Hutton, Andrew; Cullen Jennings
>Cc: rtcweb@ietf.org; public-webrtc@w3.org
>Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case
>
>
>Hi,
>
>> IIUC, your proposal is to update JSEP SDP_PRANSWER and SDP_ANSWER = as
>> equivalent to moreComing=3Dtrue/false in ROAP. Also, we need to >> consider
>the scenario like 18x with SDP (SDP_PRANSWER) and 2xx without SDP
>wherein JS has to take care of SDP_ANSWER even though it does not
>receive one. IMO, Multiple answer issue is not fully solved in ROAP as<= br> >well.
>
>In that case, I guess the JS app could simply take a previous
>SDP_PRANSWER, and send it as SDP_ANSWER.
>
>> Also, I have the problem in the understanding the strong need for<= br> >differentiating answer and final answer. Could you please clarify it. >
>I had exactly the same issue, but what Cullen told me last week made me=
>re-think. It's all about resources :)
>
>So, take the following example:
>
>1. The browser creates an offer, and reservers resrouces for codecs X >and Y.
>2. At some point, the browser receives a PRANSWER, with only codec X. >However, the browser still keeps the resources for Y, as a new answer >may come.
>3. At some point, the browser receives another PRANSWER (maybe forking<= br> >has occured), with only codec Y. However, the browser still keeps the >resources for X (again, as a new answer may come).
>4. At some point, the browser recieves an ANSWER, with only codec X. >Now, as this is the last answer, the browser can release the resources<= br> >for Y.
>
>So, the main difference is related to the resources associated with the=
>offer. Once a final answer (ANSWER) has been received, and resources >that were reserved for the offer, but are no longer needed, can be
>released.
>
>(Cullen, please correct me if I've missunderstood :)
>
>Regards,
>
>Christer
>
>
>>-----Original Message-----
>>From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
>>Sent: Monday, February 20, 2012 12:12 PM
>>To: Hutton, Andrew; Ravindran, Parthasarathi; Cullen Jennings
>>Cc: rtcweb@ietf.org; public-webrtc@w3.org
>>Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case
>>
>>
>>Hi,
>>
>>In my opinion, even if we do need SDP_PRANSWER (Cullen may have
>>convinced me that there is a need for it :), I don't think it s= hould
>>have an implicit "recvonly" meaning.
>>
>>PRANSWER or ANSWER, I think we shall use the SDP direction attribut= e
>>(or some other explicit elements) to indicate media direction.
>>
>>Regards,
>>
>>Christer
>>
>>
>>
>>-----Original Message-----
>>From: rtcweb-bounces@iet= f.org [mailto:rtcweb-bounces= @ietf.org] On
>>Behalf Of Hutton, Andrew
>>Sent: 19. helmikuuta 2012 23:26
>>To: Ravindran, Parthasarathi; Cullen Jennings
>>Cc: rtcweb@ietf.org; public-webrtc@w3.org
>>Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case
>>
>>Hi,
>>
>>Yes absolutely I have come across a number of scenarios in the US a= nd
>>in Europe where media is needed in the forward direction for DTMF >>input after receiving a 18x response and before the 200OK. IF I
>>remember correctly calling FEDEX was actually one of the real life = examples.
>>
>>Regards
>>Andy
>>
>>
>>> -----Original Message-----
>>> From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com]
>>> Sent: 19 February 2012 17:53
>>> To: Cullen Jennings; Hutton, Andrew
>>> Cc: public-webrtc@w3.o= rg; rtcweb@ietf.org
>>> Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case=
>>>
>>> Cullen,
>>>
>>> AFAIK, 18x with sendrecv as direction attribute & DTMF (te= lephony-
>>> event) is allowed by couple of operators in FEDEX (call center= )
>>> scenario. Andy will be able to double confirm whether he also = comes
>>> across the similar deployment.
>>>
>>> Thanks
>>> Partha
>>>
>>>
>>>
>>> >-----Original Message-----
>>> >From: rtcweb-bo= unces@ietf.org [mailto:rtcwe= b-bounces@ietf.org] On
>>> Behalf
>>> >Of Cullen Jennings
>>> >Sent: Saturday, February 18, 2012 2:29 AM
>>> >To: Hutton, Andrew
>>> >Cc: public-webrtc@= w3.org; rtcweb@ietf.org
>>> >Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-= case
>>> >
>>> >
>>> >On Feb 16, 2012, at 1:04 PM, Hutton, Andrew wrote:
>>> >
>>> >>> (Also, in the FEDEX case, there could be scenario= s where the
>>> browser
>>> >>> does need to transit media, if the user is e.g. p= romted for
>>> >>> DTMFs, voice commands etc...)
>>> >>>
>>> >>
>>> >> [AndyH] - I agree that media transmission is required= at this
>>> >> stage
>>> so
>>> >that the user can navigate through voice prompts (E.g. via= DTMF) I
>>> >thought this was the main requirement from the FEDEX use c= ase.
>>> >
>>> >that's not my understanding. My understanding was it w= as one way
>>> >media until the final response in the early media case. An= d the IVR
>>> >sends
>>> the
>>> >first prompt as ringtone but cuts over before two way medi= a (IE
>>> >DTMF)
>>> is
>>> >needed. The whole point of this hack is to cut the time th= e IVR
>>> >gets billed for but the SP is not going to provide two way= media
>>> >before billing starts.
>>> >
>>> >
>>> >_______________________________________________
>>> >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

--14dae9c09a9e68ada004b96b4474-- From ibc@aliax.net Mon Feb 20 12:43: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 CA4F321F84FE for ; Mon, 20 Feb 2012 12:43:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.622 X-Spam-Level: X-Spam-Status: No, score=-2.622 tagged_above=-999 required=5 tests=[AWL=0.055, 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 bqI4-5uYO5Ya for ; Mon, 20 Feb 2012 12:43:48 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 32AD321F84FC for ; Mon, 20 Feb 2012 12:43:48 -0800 (PST) Received: by vcbfk14 with SMTP id fk14so4384882vcb.31 for ; Mon, 20 Feb 2012 12:43:47 -0800 (PST) Received-SPF: pass (google.com: domain of ibc@aliax.net designates 10.52.26.8 as permitted sender) client-ip=10.52.26.8; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ibc@aliax.net designates 10.52.26.8 as permitted sender) smtp.mail=ibc@aliax.net Received: from mr.google.com ([10.52.26.8]) by 10.52.26.8 with SMTP id h8mr10501542vdg.122.1329770627677 (num_hops = 1); Mon, 20 Feb 2012 12:43:47 -0800 (PST) Received: by 10.52.26.8 with SMTP id h8mr8428460vdg.122.1329770627547; Mon, 20 Feb 2012 12:43:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.203.2 with HTTP; Mon, 20 Feb 2012 12:43:25 -0800 (PST) In-Reply-To: References: <7F2072F1E0DE894DA4B517B93C6A05852C3D87E060@ESESSCMS0356.eemea.ericsson.se> <3CBDF06F-F52D-4C09-A78F-1A0D8479572A@iii.ca> <7F2072F1E0DE894DA4B517B93C6A05852C3D87E58F@ESESSCMS0356.eemea.ericsson.se> <101C6067BEC68246B0C3F6843BCCC1E31202EDA663@MCHP058A.global-ad.net> <15CD1ECE-6BDD-4EE0-AA5B-EF40616578CD@iii.ca> <387F9047F55E8C42850AD6B3A7A03C6C0E040A1D@inba-mail01.sonusnet.com> <101C6067BEC68246B0C3F6843BCCC1E312942242CD@MCHP058A.global-ad.net> <7F2072F1E0DE894DA4B517B93C6A05852C3D8C60E1@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E040C04@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C3D8C6134@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E040C6D@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C3D8C630B@ESESSCMS0356.eemea.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 20 Feb 2012 21:43:25 +0100 Message-ID: To: Roman Shpount Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmTqn7HzwzZbsmS8uila0Xl9oSKgNH3C1Iq6k66W2C+eMMxSa54/sevuZQpVSA1MAeDiBkJ Cc: "public-webrtc@w3.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case 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, 20 Feb 2012 20:43:48 -0000 2012/2/20 Roman Shpount : > Actually codecs are a fairly bad example, since end point should be ready= to > receive media=C2=A0 encoded using any codec present in the offer. The fac= t that > one of the codecs was not present in the answer does not mean that remote > party is not planning to send media using this codec. Exactly. At least SDP offer/answer mechanism allows asymmetric codecs usage in the same media session, which means different codec in each direction of the media stream. --=20 I=C3=B1aki Baz Castillo From sohel_khan@cable.comcast.com Mon Feb 20 13:42: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 9053821F85D9 for ; Mon, 20 Feb 2012 13:42:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.5 X-Spam-Level: X-Spam-Status: No, score=-105.5 tagged_above=-999 required=5 tests=[AWL=2.663, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 whoEiZvxxjMt for ; Mon, 20 Feb 2012 13:42:32 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 4E18C21F859E for ; Mon, 20 Feb 2012 13:42:32 -0800 (PST) Received: from ([24.40.56.114]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.151857436; Mon, 20 Feb 2012 16:42:28 -0500 Received: from PACDCEXMB02.cable.comcast.com ([fe80::9803:aba4:1ac8:474e]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0355.002; Mon, 20 Feb 2012 16:42:28 -0500 From: "Khan, Sohel" To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , "rtcweb@ietf.org" Thread-Topic: [rtcweb] draft-ietf-rtcweb-security-arch-00 Thread-Index: Aczv21xh2pHouKjZSAeypXuScTchkQANT7EAAADfuFA= Date: Mon, 20 Feb 2012 21:42:27 +0000 Deferred-Delivery: Mon, 20 Feb 2012 21:42:00 +0000 Message-ID: <837E772D16C77141BFA5FEC3F30487FF525BF7A4@PACDCEXMB02.cable.comcast.com> References: <837E772D16C77141BFA5FEC3F30487FF525BF54C@PACDCEXMB02.cable.comcast.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.40.56.171] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [rtcweb] draft-ietf-rtcweb-security-arch-00 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, 20 Feb 2012 21:42:33 -0000 VGhhbmtzIEluYWtpLiBJdCBjYW4gYmUgb25lIG9mIHRoZSBtZXRob2RzLg0KIEl0IHdpbGwgYmUg bmljZSB0byBhZGQgdGhlIFNJUCBhbmQgV2ViIHRydXN0IG1vZGVscyBhc3NvY2lhdGlvbiBpbiBF cmljJ3MgZHJhZnQuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBJw7Fha2kg QmF6IENhc3RpbGxvIFttYWlsdG86aWJjQGFsaWF4Lm5ldF0gDQpTZW50OiBNb25kYXksIEZlYnJ1 YXJ5IDIwLCAyMDEyIDEwOjQ2IEFNDQpUbzogS2hhbiwgU29oZWwNCkNjOiBydGN3ZWJAaWV0Zi5v cmcNClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBkcmFmdC1pZXRmLXJ0Y3dlYi1zZWN1cml0eS1hcmNo LTAwDQoNCjIwMTIvMi8yMCBLaGFuLCBTb2hlbCA8U29oZWxfS2hhbkBjYWJsZS5jb21jYXN0LmNv bT46DQo+IFRoYW5rIHlvdSBmb3IgdGhlIFJUQ1dFQiBTZWN1cml0eSBBcmNoaXRlY3R1cmUgZHJh ZnQuIFNvbWUgU0lQIG9yIA0KPiB0ZWxjby1jZW50cmljIGltcGxlbWVudGVycyBtYXkgbmVlZCB0 byB1bmRlcnN0YW5kIHRoZSBSVENXZWIgdHJ1c3QgDQo+IG1vZGVsIHZpc3VhbGl6aW5nIGluIHRo ZSBjb250ZXh0IG9mIFNJUCBSRUdJU1RFUiBtZXRob2QuIFdvdWxkIGl0IGJlIA0KPiBwb3NzaWJs ZSB0byBhZGQgYSBzZWN0aW9uIGluIHlvdXIgZHJhZnQgd2l0aCBhbiBleGFtcGxlIGRlc2NyaWJp bmcgdGhlIA0KPiBXZWIgVHJ1c3QgbW9kZWwgdGhhdCBtaWdodCBiZSB1c2VkIGZvciB0aGUgwqBS VENXZWIgYW5kIA0KPiBjb21wYXJlL2NvbnRyYXN0IHRoYXQgd2l0aCBTSVAgUkVHSVNURVIgbWV0 aG9kPyDCoFRoaXMgc2VjdGlvbiB3aWxsIGJlIA0KPiB2ZXJ5IGJlbmVmaWNpYWwgdG8gdGhlIFNJ UCBvciB0ZWxjby1jZW50cmljIGltcGxlbWVudGVycywgd2hvIGFyZSB1c2VkIHRvIFNJUCBSRUdJ U1RFUiB0cnVzdCBtb2RlbC4NCg0KSSB3b3VsZCBqdXN0IHNlbmQgYSByZWFsIFNJUCBSRUdJU1RF UiByZXF1ZXN0IHZpYSBXZWJTb2NrZXQgOikNCg0KLS0NCknDsWFraSBCYXogQ2FzdGlsbG8NCjxp YmNAYWxpYXgubmV0Pg0K From randell-ietf@jesup.org Mon Feb 20 14:03: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 0E52D21E8011 for ; Mon, 20 Feb 2012 14:03:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[AWL=-0.101, BAYES_00=-2.599, J_CHICKENPOX_65=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 15COnnqke6u3 for ; Mon, 20 Feb 2012 14:03:06 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 39D4821E800C for ; Mon, 20 Feb 2012 14:03:06 -0800 (PST) Received: from pool-173-49-135-74.phlapa.fios.verizon.net ([173.49.135.74] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RzbK4-0004Xn-7x; Mon, 20 Feb 2012 16:03:04 -0600 Message-ID: <4F42C2C7.3060802@jesup.org> Date: Mon, 20 Feb 2012 17:01:43 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "rtcweb@ietf.org" , "public-webrtc@w3.org" References: <7F2072F1E0DE894DA4B517B93C6A05852C3D31BA37@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C3D31BA3A@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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] JSEP-02: New offer and answer to previous offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case] 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, 20 Feb 2012 22:03:07 -0000 On 2/20/2012 3:31 PM, Roman Shpount wrote: > Not to beat this horse to death, but why is it "suggested not to have > parallel forking"? WebRTC intorduces additional restrictions on RTP > stream (remote media sources and SSRCs are known in advance) that make > parallel forking implementation trivial. Only thing that is missing is > some way to clone the PeerConnection in the API. Right; parallel forking has uses. We've talked about this, but not for a while. One way to implement it would be to on each forked answer clone the state of the PeerConnection as it was with any previous answer removed. However, I'm concerned about how this will interact with the ICE, etc stuff. Someone want to throw out a suggestion? Cullen, Justin - how *should*/*could* forking work within JSEP? Aside on uses of forking: I can see some additional interesting uses for parallel forking, especially in non-phone-like usecases (games among others). The server (or another participant) could hold open an OFFER in order to forward it to any potential new partners. This might apply to a conference call as well if there's a peer-2-peer aspect (mesh, partial-mesh, etc) to it. Think in a game or 2nd-life-type-sim, where you're automatically in a voice chat with anyone within hearing range, and those voice chats are done p2p by forking each player's original offer to the server, and forwarding it (forking it) to the new user, who would answer and they'd be in a call. If you wanted to get really fancy, you could even do some of the negotiation in the server and rephrase each offer as an answer to the other side, leading to a 1/2-RTT-to-the-server setup time (more-or-less: player 1 server player 2 ------------------------------------------------------------ | | | |--> Offer 1 ---------------->| | | |<---------- Offer 2 <----| | | | ... Server decides they should talk | | | |<-- Answer(Offer 2) <--------|-----> Answer(Offer 1)-->| |<------------------------- media --------------------->| Even if this is initiated by a player, there are equivalent graphs that use 1/2 RTT (through the server to other player) to set up channels. I should note however that ICE overhead may well swamp this fancy setup and it may be over-reaching, but each 1/2 RTT removed is significant, so there may be uses. > _____________ > Roman Shpount > > > On Mon, Feb 20, 2012 at 3:14 PM, Christer Holmberg > > > wrote: > > > Hi, > > Just to clarify: the new offer is for the same "session" as the > previous offer, and is supposed to replace the previous offer. > > The browser can of course send a just-audio offer somewhere, and a > just-video offer somewhere else, but would those even be associated > with the same PeerConnection? I thought we wanted only one > offer/answer, which is the reason it has been suggested e.g. not to > support paralell forking in the browser. > > Regards, > > Christer > ________________________________________ > From: Iñaki Baz Castillo [ibc@aliax.net ] > Sent: Monday, February 20, 2012 10:13 PM > To: Christer Holmberg > Cc: Justin Uberti; rtcweb@ietf.org ; > public-webrtc@w3.org > Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous > offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case] > > 2012/2/20 Christer Holmberg >: > > Q1. When the JS app requests the new offer (o-2), I assume all > resources etc associated with o-1 will be released (unless they are > also needed for o-2, that is). > > Does it mean that the browser is just capable of having *one* > multimedia session at the same time? Well, in SIP world this typically > means putting on-hold the previous call so, indeed, resources would be > released. > > But, why couldn't the browser send a just-audio offer somewhere and a > just-video offer to other destination at the same time? > > -- > Iñaki Baz Castillo > > > _______________________________________________ > 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 -- Randell Jesup randell-ietf@jesup.org From richard.ejzak@alcatel-lucent.com Mon Feb 20 15:35: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 3F4E621F85DA for ; Mon, 20 Feb 2012 15:35:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6KqlsbHSyknP for ; Mon, 20 Feb 2012 15:35:56 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0C20C21F85D9 for ; Mon, 20 Feb 2012 15:35:53 -0800 (PST) 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 q1KNZq6o024630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 20 Feb 2012 17:35:52 -0600 (CST) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q1KNZpKT018351 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 20 Feb 2012 17:35:52 -0600 Received: from USNAVSXCHMBSA1.ndc.alcatel-lucent.com ([135.3.39.126]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Mon, 20 Feb 2012 17:35:51 -0600 From: "Ejzak, Richard P (Richard)" To: "rtcweb@ietf.org" Date: Mon, 20 Feb 2012 17:35:50 -0600 Thread-Topic: [rtcweb] JSEP-02: New offer and answer to previous offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case] Thread-Index: AczwG28IlnT7EseTRhK+LpHfGgyCRgAB/TOA Message-ID: <6F428EFD2B8C2F49A2FB1317291A76C1135557E033@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> References: <7F2072F1E0DE894DA4B517B93C6A05852C3D31BA37@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C3D31BA3A@ESESSCMS0356.eemea.ericsson.se> <4F42C2C7.3060802@jesup.org> In-Reply-To: <4F42C2C7.3060802@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-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case] 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, 20 Feb 2012 23:35:57 -0000 I am concerned about an earlier suggestion that multiple SDP answers can be= handled in SIP by forking separate dialogs without supporting forking of t= he media streams. =20 This raises some questions: Is there a difference between multiple answers = within a dialog (not currently supported in SIP and RFC 3264 but presumably= a behavior some would like to be supported) and parallel forking? Is it u= nderstood that all PRANSWERs and ANSWERs are in separate dialogs? Or can t= here be multiple PRANSWERs associated with a final ANSWER for a forked dial= og? If we are to support forking then there has to be a clear way of assoc= iating sets of (PR)ANSWERs with each dialog (this concept still remains val= id if the signaling protocol is not SIP) and how to resolve resource confli= cts between them. Richard Ejzak From pravindran@sonusnet.com Mon Feb 20 19:51: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 DE36421E8036 for ; Mon, 20 Feb 2012 19:51:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 3DzbZzzYHC9a for ; Mon, 20 Feb 2012 19:51:59 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 1625B21E8034 for ; Mon, 20 Feb 2012 19:51:58 -0800 (PST) Received: from sonusmail07.sonusnet.com (sonusmail07.sonusnet.com [10.128.32.157]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q1L3qgZs017953; Mon, 20 Feb 2012 22:52:42 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 Feb 2012 22:51:54 -0500 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Feb 2012 09:22:07 +0530 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; Tue, 21 Feb 2012 09:22:06 +0530 From: "Ravindran, Parthasarathi" To: "Ejzak, Richard P (Richard)" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] JSEP-02: New offer and answer to previous offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case] Thread-Index: AQHM8AqE+28vByK84kKxG08H/gll95ZF3BIAgAAASYCAAASXgIAAGTuAgAAaTACAAKIqAA== Date: Tue, 21 Feb 2012 03:52:05 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E040F9B@inba-mail01.sonusnet.com> References: <7F2072F1E0DE894DA4B517B93C6A05852C3D31BA37@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C3D31BA3A@ESESSCMS0356.eemea.ericsson.se> <4F42C2C7.3060802@jesup.org> <6F428EFD2B8C2F49A2FB1317291A76C1135557E033@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> In-Reply-To: <6F428EFD2B8C2F49A2FB1317291A76C1135557E033@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 21 Feb 2012 03:52:07.0072 (UTC) FILETIME=[2E3B4A00:01CCF04C] Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case] 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, 21 Feb 2012 03:52:00 -0000 Richard, I didn't understand your question w.r.t SIP. As per RFC 3261, SIP UAC with = RTP endpoint (not RTP mixer) also MUST support multiple SDP answers in case= of (serial & parallel) forked responses. It is matter of SIP UA applicatio= n design to accommodate those callflows. Hi all, My concern with PRANSWER state in offer/answer (O/A) model is that JSEP JS = application will be more complicated than SIP UA application as SIP UA appl= ication O/A has only two states (offer & answer) whereas JSEP JS has to mai= ntain 3 states with different set of responses.=20 Thanks Partha >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of Ejzak, Richard P (Richard) >Sent: Tuesday, February 21, 2012 5:06 AM >To: rtcweb@ietf.org >Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous offer >[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] > >I am concerned about an earlier suggestion that multiple SDP answers can >be handled in SIP by forking separate dialogs without supporting forking >of the media streams. > >This raises some questions: Is there a difference between multiple >answers within a dialog (not currently supported in SIP and RFC 3264 but >presumably a behavior some would like to be supported) and parallel >forking? Is it understood that all PRANSWERs and ANSWERs are in >separate dialogs? Or can there be multiple PRANSWERs associated with a >final ANSWER for a forked dialog? If we are to support forking then >there has to be a clear way of associating sets of (PR)ANSWERs with each >dialog (this concept still remains valid if the signaling protocol is >not SIP) and how to resolve resource conflicts between them. > >Richard Ejzak > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From juberti@google.com Mon Feb 20 20:50: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 B435621E8036 for ; Mon, 20 Feb 2012 20:50:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.769 X-Spam-Level: X-Spam-Status: No, score=-102.769 tagged_above=-999 required=5 tests=[AWL=0.207, 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 HvkYIw+3Rp0t for ; Mon, 20 Feb 2012 20:50:33 -0800 (PST) Received: from mail-qw0-f49.google.com (mail-qw0-f49.google.com [209.85.216.49]) by ietfa.amsl.com (Postfix) with ESMTP id 1947E21E8016 for ; Mon, 20 Feb 2012 20:50:33 -0800 (PST) Received: by qadc14 with SMTP id c14so6774220qad.15 for ; Mon, 20 Feb 2012 20:50:32 -0800 (PST) Received-SPF: pass (google.com: domain of juberti@google.com designates 10.229.135.85 as permitted sender) client-ip=10.229.135.85; Authentication-Results: mr.google.com; spf=pass (google.com: domain of juberti@google.com designates 10.229.135.85 as permitted sender) smtp.mail=juberti@google.com; dkim=pass header.i=juberti@google.com Received: from mr.google.com ([10.229.135.85]) by 10.229.135.85 with SMTP id m21mr18307949qct.26.1329799832628 (num_hops = 1); Mon, 20 Feb 2012 20:50:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=QrjvsH+sMO2w4+4tpFW9uDIhhjfdvGq0O76wNFKr06s=; b=eeEGcQF8WhJ8vXIWNzbr+DBlZr54mGrYOgOv7TVmknO/UWpAIhXeXmJJizDR0vydU+ c7IcX+V5zus/C9Fn6RYBYgdmi4tKJPul9dhZo6fsY+/ig95niU93hT+o1yGBEjXsuQ1c LvqQY5nB/1B7TkOvp42ch4uAP+pJKfBB8+A7M= Received: by 10.229.135.85 with SMTP id m21mr15468771qct.26.1329799832429; Mon, 20 Feb 2012 20:50:32 -0800 (PST) Received: by 10.229.135.85 with SMTP id m21mr15468698qct.26.1329799830345; Mon, 20 Feb 2012 20:50:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.29.195 with HTTP; Mon, 20 Feb 2012 20:50:10 -0800 (PST) In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E040B37@inba-mail01.sonusnet.com> References: <387F9047F55E8C42850AD6B3A7A03C6C0E03F8A4@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E03FAB5@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E03FB7C@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E03FC20@inba-mail01.sonusnet.com> <9ED4A9AC-37C7-4E6D-B6C6-4D3C9537B356@iii.ca> <387F9047F55E8C42850AD6B3A7A03C6C0E040130@inba-mail01.sonusnet.com> <935E62D2-61EB-4E53-98D7-E2BC78AC0B41@iii.ca> <387F9047F55E8C42850AD6B3A7A03C6C0E040B37@inba-mail01.sonusnet.com> From: Justin Uberti Date: Mon, 20 Feb 2012 23:50:10 -0500 Message-ID: To: "Ravindran, Parthasarathi" Content-Type: multipart/alternative; boundary=00248c6a7a8e82985404b9722601 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnlf5HBFUMgIFvaAUyg40MMKaeyQqBytM5O7o5EzfWy8uuFwJCCVoA35hIc2TlAR6V8zdeEYtmiRJZQXrtrQlqNeWDwFOdDS8q/PHP/pdb5HVdG7cbod1o65EZsk3g0aqWMuUPT12OoVg4XXL31Wg9dCjPxOw== Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] Single offer with multiple answer handling in JSEP [was RE: New JSEP draft posted] 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, 21 Feb 2012 04:50:36 -0000 --00248c6a7a8e82985404b9722601 Content-Type: text/plain; charset=UTF-8 Partha, Thanks for these example flows. I'm out on vacation this week but will try to distill and incorporate the consensus on this topic when I return. Regards, --justin On Sun, Feb 19, 2012 at 2:25 PM, Ravindran, Parthasarathi < pravindran@sonusnet.com> wrote: > Cullen, > > As I mentioned below, the problem statement is for multiple answer and > multiple 200 is one of the IETF SIP (RFC 3261) defined multiple answer > usecase. Deployed (real) SIP world usecase for multiple answer exists in > form of 18x with answer1 and 2xx with answer2 for INVITE offer. I > worked/interoped with multiple well deployed implementation which supports > "receiving" multiple answer with slight different variance (and no UPDATE > [RFC 3311] in the middle) and I'm sure more implementation exists. The > reason for allowing "receiving" multiple answer is leniency while receiving > the SIP message which is generally accepted in Product development. Even > though some of the deployed implementation violates RFC 3264 for the noble > reason of reducing the number of SIP messages (no UPDATE Offer/answer > transaction after 18x) for the basic call, it is possible to make those > implementation SIP RFC compliance by changing 18x To-Tag, Please look into > "18x with SDP and 2xx with different SDP & To Tag" attachment for more > details. > > Also, 18x with SDP and 2xx without SDP is the another set implementation > exists as mentioned in "18x with SDP and 2xx without SDP" attachment. In > case these details are not enough, I'll add Multiple 18x with different 2xx > callflow later. > > Keeping aside SIP deployment, I'm still not convinced why browser MUST be > restricted from multiple answer as I didn't see the technical reason for > restricting. As I mentioned, Fixed-Mobile application is possible to > implement using this mechanism and WebRTC shall provide the building block > for it. The callflow is shown in "Single Offer Multiple Answer callflow" > example. > > AFAIK, offer results in RTP port allocation in the resource manager and > SRTP key generation. In case first answer is received, those resources are > required irrespective of multiple answer will receive or not. In case your > argument is about pre-allocated (RSVP kind of) bandwidth for offer, those > specific WebRTC applications are free to reject the second answer onwards > and consider first answer as the final answer, so this proposal in not > limiting those applications. Could you please clarify any other list of > resources lock/leak in your mind due to offer for my understanding. I'm > asking this query as I get the feeling from other mail threads that > resource lock/leak is one of the reason for requesting final answer by you. > > Justin, > > I have added 3 callflow as a starting point for the discussion which shall > be added later in case consensus is reached. I'll provide multiple 18x with > different order 2xx later. > > Thanks > Partha > > >-----Original Message----- > >From: Cullen Jennings [mailto:fluffy@iii.ca] > >Sent: Saturday, February 18, 2012 2:51 AM > >To: Justin Uberti > >Cc: Ravindran, Parthasarathi; rtcweb@ietf.org; public-webrtc@w3.org > >Subject: Re: [rtcweb] Single offer with multiple answer handling in JSEP > >[was RE: New JSEP draft posted] > > > > > >I'm most interested in real world use cases which if they were being > >done with SIP would result in multiple 200 being processed by the > >browser. I have not got my head around why this would be needed yet and > >without the use cases I'm having a hard time deciding if there is a > >problem or not. > > > > > >On Feb 16, 2012, at 7:35 PM, Justin Uberti wrote: > > > >> Agree it has not been addressed. I'm having some trouble understanding > >the exact flows that we need to address here (multiple 2xx, multiple 18x > >followed by 2xx, multiple 18x followed by multiple 2xx) but if I > >understand correctly your suggestion was: > >> > >> 1) allow a setRemoteDesc(SDP_ANSWER) to follow a > >> setRemoteDesc(SDP_ANSWER) > >> 2) document that in this case (multiple 2xx), the JS is responsible > >for sending BYE to the previous answerer. > >> > >> which sounds totally reasonable to me. > >> > >> If this sounds good to you, would you mind sketching out a call flow > >that I could include in the examples section? > >> > >> On Thu, Feb 16, 2012 at 2:11 AM, Ravindran, Parthasarathi > > wrote: > >> Cullen/Justin, > >> > >> Single offer with multiple answer open item is not addressed in -02 > >version of JSEP draft. Hope you first agree this as an open item in > >JSEP. > >> > >> Thanks > >> Partha > >> > >> >-----Original Message----- > >> >From: Ravindran, Parthasarathi > >> >Sent: Wednesday, February 15, 2012 2:43 PM > >> >To: 'Cullen Jennings' > >> >Cc: Justin Uberti; rtcweb@ietf.org; public-webrtc@w3.org > >> >Subject: RE: [rtcweb] Single offer with multiple answer handling in > >> >JSEP [was RE: New JSEP draft posted] > >> > > >> >Cullen, > >> > > >> >RFC3261 references for receiving multiple 2xx in UAC which does not > >> >fork INVITE are as follows: > >> > > >> > > >> >Sec 13.1 Para 3: > >> > > >> >Therefore, when multiple 2xx responses are received from different > >> >remote UAs (because the INVITE forked), each 2xx establishes a > >> >different dialog. All these dialogs are part of the same call. > >> > > >> >Sec 13.2.2.4 2xx Responses > >> > > >> > Multiple 2xx responses may arrive at the UAC for a single INVITE > >> > request due to a forking proxy. Each response is distinguished by > >> > the tag parameter in the To header field, and each represents a > >> > distinct dialog, with a distinct dialog identifier. > >> > > >> > If, after acknowledging any 2xx response to an INVITE, the UAC > >does > >> > not want to continue with that dialog, then the UAC MUST terminate > >> > the dialog by sending a BYE request as described in Section 15. > >> > > >> > > >> >As per the last statements, it is upto the SIP application to decide > >> >which one of the final 2xx response has to be included within the > >call. > >> >The usecase 3 is based on RFC3262 (PRACK) support wherein it is > >> >possible to receive multiple forked 18x with SDP followed by 2xx with > >> >or without SDP and SIP 2xx response is not tied to offer/answer > >exchange. > >> > > >> >I have provided mobile to desktop as an example to justify the last > >> >answer may be used in the offer in some JS application. As I > >> >mentioned below, there is no need to restrict updating latest answer > >> >for an offer in terms of API and protocol. > >> > > >> >Thanks > >> >Partha > >> > > >> >>-----Original Message----- > >> >>From: Cullen Jennings [mailto:fluffy@iii.ca] > >> >>Sent: Wednesday, February 15, 2012 1:31 PM > >> >>To: Ravindran, Parthasarathi > >> >>Cc: Justin Uberti; rtcweb@ietf.org; public-webrtc@w3.org > >> >>Subject: Re: [rtcweb] Single offer with multiple answer handling in > >> >>JSEP [was RE: New JSEP draft posted] > >> >> > >> >> > >> >>I'm a bit lost on use case in SIP context - assuming that the UAC > >> >>did not fork but that a proxy or B2BUA did the forking, it seems > >> >>like the UAC should never receive more than one final response. > >> >> > >> >>In the case of moving from desktop to mobile, it seems like that is > >> >>updating the stream and would use a call flow more like update > >> >>examples in the draft instead of trying to reuse some old answer. > >> >> > >> >> > >> >>On Feb 14, 2012, at 11:24 , Ravindran, Parthasarathi wrote: > >> >> > >> >>> Justin, > >> >>> > >> >>> Some of the usecases could be > >> >>> 1) The same user of a website signed-in in the multiples > >devices > >> >>and acts as answerer, the session establishment request to the > >> >>identity will alert all the signed-in devices and it is possible > >> >>that multiple devices answer to the session. Here, user may move > >> >>from one device > >> >>(mobile) to another device (desktop) within the session and wishes > >> >>to continue the session with the last answer. Please note that > >> >>website is flexible to provide this service. > >> >>> 2) RFC 3261 SIP UA offer/answer handling w.r.t INVITE with > >SDP > >> >to > >> >>multiple 2xx with SDP handling scenario using JSEP > >> >>> 3) Another SIP usecase could be multiple 18x responses with > >SDP > >> >>for INVITE with SDP and multiple 2xx responses without SDP but order > >> >>within 18x and 200 are not same. Say 2xx of the second 18x is > >> >>received as the first 2xx. Here, we need to know how second 18x is > >> >>handled and also, the subsequent 2xx is handled. > >> >>> > >> >>> Of course, it is possible to build more usecases around this area. > >> >>> As > >> >>we made signaling outside the scope of WebRTC, it is upto JS > >> >>application to decide the order in which offer/answer happens. I'm > >> >>not relating offer/answer FSM with session establishment state like > >> >>18x, 2xx but I'm interested in knowing browser media plane behavior > >> >>in different state of offer/answer handling by which JS application > >> >>behaves consistently in all browsers. > >> >>> > >> >>> Thanks > >> >>> Partha > >> >>> > >> >>> > >> >>> From: Justin Uberti [mailto:juberti@google.com] > >> >>> Sent: Tuesday, February 14, 2012 11:36 PM > >> >>> To: Ravindran, Parthasarathi > >> >>> Cc: rtcweb@ietf.org; public-webrtc@w3.org > >> >>> Subject: Re: Single offer with multiple answer handling in JSEP > >> >>> [was > >> >>RE: [rtcweb] New JSEP draft posted] > >> >>> > >> >>> Partha, > >> >>> > >> >>> I need more information about the use case to provide an accurate > >> >>response. As mentioned in my earlier mail, are both answers 2xx > >> >>responses? > >> >>> > >> >>> On Tue, Feb 14, 2012 at 12:17 PM, Ravindran, Parthasarathi > >> >> wrote: > >> >>> Hi Justin, > >> >>> > >> >>> In this mail thread, Let us define the behavior of multiple > >> >>> (atleast > >> >>two) answers for the single offer in WebRTC browser. Now, Please > >> >>let me know your opinion for my below mail. > >> >>> > >> >>> Thanks > >> >>> Partha > >> >>> > >> >>> From: Justin Uberti [mailto:juberti@google.com] > >> >>> Sent: Tuesday, February 14, 2012 9:47 PM > >> >>> > >> >>> To: Ravindran, Parthasarathi > >> >>> Cc: rtcweb@ietf.org; public-webrtc@w3.org > >> >>> Subject: Re: Single offer with multiple answer handling in JSEP > >> >>> [was > >> >>RE: [rtcweb] New JSEP draft posted] > >> >>> > >> >>> > >> >>> > >> >>> On Tue, Feb 14, 2012 at 6:39 AM, Ravindran, Parthasarathi > >> >> wrote: > >> >>> Hi Justin, > >> >>> > >> >>> It will be good to mention in the JSEP draft that multiple > >> >>> answers > >> >>for single offer will not lead to RTP Mixing and WebRTC client acts > >> >>as RTP Endpoint. > >> >>> > >> >>> Failing the second Answer will be limiting the provision in RFC > >> >>> 3264 > >> >>offer/answer itself as RFC 3264 supports single offer with multiple > >> >>answer. Also, it is better to define the behavior in API rather than > >> >>putting this scenario in the browser implementation specific. In > >> >>simple scenarios (like alerting with one answer, connect with second > >> >>answer), replacing the previous ANSWER will be expected behavior. > >> >>This may not be desired behavior in case two connect responses from > >> >>different WebRTC clients received with different answers but there > >> >>is no other alternative solution possible without mixing. > >> >>> > >> >>> Do you need to support 2 final answers, or would the provisional > >> >>answer support provided via SDP_PRANSWER work for you? > >> >>> > >> >>> IMO, it is better to define it explicitly in JSEP that "latest > >> >>> ANSWER > >> >>to the offer will replace the existing answer is the expected > >> >>behavior ". Also, Please mentioned that JS application is > >responsible for > >> >>discarding (terminating) previous ANSWER notification. Please let > >me > >> >>your opinion on this closure. > >> >>> > >> >>> Thanks > >> >>> Partha > >> >>> > >> >>> From: Justin Uberti [mailto:juberti@google.com] > >> >>> Sent: Tuesday, February 14, 2012 7:29 PM > >> >>> To: Ravindran, Parthasarathi > >> >>> Cc: rtcweb@ietf.org; public-webrtc@w3.org > >> >>> Subject: Re: Single offer with multiple answer handling in JSEP > >> >>> [was > >> >>RE: [rtcweb] New JSEP draft posted] > >> >>> > >> >>> Regarding your previous mail, an ANSWER after an ANSWER would > >> >>> either > >> >>fail (if we wanted to simplify), or replace the previous ANSWER > >> >>(essentially the same as if you had done setLocalDescription(OFFER, > >> >>localDescription) followed by setRemoteDescription(ANSWER, answer2). > >> >>> > >> >>> In no case would it mix the descriptions/media from both answers. > >> >>> > >> >>> Other comments inline below. > >> >>> > >> >>> On Tue, Feb 14, 2012 at 1:24 AM, Ravindran, Parthasarathi > >> >> wrote: > >> >>> Hi Justin, > >> >>> > >> >>> Adding to my earlier mail, In case answer2 SDP is updated in > >> >>> offerer1 > >> >>browser without notifying answerer1, then answer1 will continue to > >> >>transmit RTP which may not be desired behavior. IMO, we need to > >> >>define this behavior clearly in offerer side. Some of the possible > >> >>solutions are > >> >>> > >> >>> 1) offerer1 has to send atleast RTCP BYE packets towards > >> >>answerer1 while accepting the answerer2 SDP. > >> >>> > >> >>> 2) Throw callback to clear answer1 SDP towards offererJS. > >> >>> > >> >>> > >> >>> The application which called setRemoteDescription twice should > >> >>> have > >> >>the best idea about what is going on, and therefore is responsible > >> >>for notifying answerer1 that its answer has been discarded, if it > >> >>makes sense to do so. No callback should be needed here. > >> >>> > >> >>> > >> >>> Please let me know your opinion here. > >> >>> > >> >>> Thanks > >> >>> Partha > >> >>> > >> >>> From: Ravindran, Parthasarathi > >> >>> Sent: Tuesday, February 14, 2012 12:07 AM > >> >>> To: 'Justin Uberti'; rtcweb@ietf.org; public-webrtc@w3.org > >> >>> Subject: Single offer with multiple answer handling in JSEP [was > >RE: > >> >>[rtcweb] New JSEP draft posted] > >> >>> > >> >>> Hi Justin, > >> >>> > >> >>> In the draft, it is not spelled out explicitly what is the > >> >>> expected > >> >>behavior in offerer browser in case multiple answer is received for > >> >>single offer. Offer/answer exchange in offerer is as follows: > >> >>> > >> >>> OffererJS->OffererUA: var offer = pc.createOffer(null); > >> >>> OffererJS->OffererUA: pc.setLocalDescription(SDP_OFFER, offer); > >> >>> OffererJS->OffererUA: pc.setRemoteDescription(SDP_ANSWER, > >> >>> OffererJS->answer1); > >> >>> OffererUA->Answerer1UA: > >> >>> OffererJS->OffererUA: pc.setRemoteDescription(SDP_ANSWER, > >> >>> OffererJS->answer2); > >> >>> OffererUA->Answerer?UA: ? > >> >>> > >> >>> My understanding is that "answer2" will update "answer1" in > >> >>> browser > >> >>and starting sending/receiving media towards answer2 media IP and > >port. > >> >>Could you please explain the expected behavior in offerer browser > >> >>whether it updates the media stream based on the last answer or > >> >>mixes both answerer. > >> >>> > >> >>> Thanks > >> >>> Partha > >> >>> > >> >>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > >> >>Behalf Of Justin Uberti > >> >>> Sent: Thursday, February 09, 2012 2:27 AM > >> >>> To: rtcweb@ietf.org; public-webrtc@w3.org > >> >>> Subject: [rtcweb] New JSEP draft posted > >> >>> > >> >>> Now available at http://www.ietf.org/id/draft-uberti-rtcweb-jsep- > >> >>01.txt > >> >>> > >> >>> Includes changes based on implementation feedback, and I believe > >> >>> it > >> >>addresses most of the concerns raised in last week's interim > >meetings: > >> >>> - Initial documentation provided for each API call, and what state > >> >>changes it causes > >> >>> - More examples, including a complete basic sample application > >> >>> - Simplified approach to trickle candidate handling > >> >>> - Resolved concerns about how to separate SDP attributes into > >> >>> media / > >> >>transport > >> >>> - Provided encapsulation for SDP blobs and ICE candidate lines, in > >> >>> the > >> >>event we want to change encodings or provide helper functions for JS > >> >>> - Provided mechanism for limiting candidates to TURN-only > >> >>> - Resolved several implementation issues > >> >>> > >> >>> I have not yet addressed the non-overlapping codec concern > >> >>> mentioned > >> >>in the interim meeting. I think there are ways of handling this > >> >>either in the application or the implementation, but I wanted to get > >> >>this -01 out first for feedback. > >> >>> > >> >>> > >> >>> > >> >>> _______________________________________________ > >> >>> rtcweb mailing list > >> >>> rtcweb@ietf.org > >> >>> https://www.ietf.org/mailman/listinfo/rtcweb > >> > >> > > --00248c6a7a8e82985404b9722601 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Partha,

Thanks for these example flows. I'm out on v= acation this week but will try to distill and incorporate the consensus on = this topic when I return.

Regards,
--jus= tin

On Sun, Feb 19, 2012 at 2:25 PM, Ravindran, = Parthasarathi <pravindran@sonusnet.com> wrote:
Cullen,

As I mentioned below, the problem statement is for multiple answer and mult= iple 200 is one of the IETF SIP (RFC 3261) defined multiple answer usecase.= Deployed (real) SIP world usecase for multiple answer exists in form of 18= x with answer1 and 2xx with answer2 for INVITE offer. I worked/interoped wi= th multiple well deployed implementation which supports "receiving&quo= t; multiple answer with slight different variance (and no UPDATE [RFC 3311]= in the middle) and I'm sure more implementation exists. The reason for= allowing "receiving" multiple answer is leniency while receiving= the SIP message which is generally accepted in Product development. Even t= hough some of the deployed implementation violates RFC 3264 for the noble r= eason of reducing the number of SIP messages (no UPDATE Offer/answer transa= ction after 18x) for the basic call, it is possible to make those implement= ation SIP RFC compliance by changing 18x To-Tag, Please look into "18x= with SDP and 2xx with different SDP & To Tag" attachment for more= details.

Also, 18x with SDP and 2xx without SDP is the another set implementation ex= ists as mentioned in "18x with SDP and 2xx without SDP" attachmen= t. In case these details are not enough, I'll add Multiple 18x with dif= ferent 2xx callflow later.

Keeping aside SIP deployment, I'm still not convinced why browser MUST = be restricted from multiple answer as I didn't see the technical reason= for restricting. As I mentioned, Fixed-Mobile application is possible to i= mplement using this mechanism and WebRTC shall provide the building block f= or it. =C2=A0The callflow is shown in "Single Offer Multiple Answer ca= llflow" example.

AFAIK, offer results in RTP port allocation in the resource manager and SRT= P key generation. In case first answer is received, those resources are req= uired irrespective of multiple answer will receive or not. In case your arg= ument is about pre-allocated (RSVP kind of) bandwidth for offer, those spec= ific WebRTC applications are free to reject the second answer onwards and c= onsider first answer as the final answer, so this proposal in not limiting = those applications. =C2=A0Could you please clarify any other list of resour= ces lock/leak in your mind due to offer for my understanding. I'm askin= g this query as I get the feeling from other mail threads that resource loc= k/leak is one of the reason for requesting final answer by you.

Justin,

I have added 3 callflow as a starting point for the discussion which shall = be added later in case consensus is reached. I'll provide multiple 18x = with different order 2xx later.

Thanks
Partha

>-----Original Message-----
>From: Cullen Jennings [mailto:fluffy@i= ii.ca]
>Sent: Saturday, February 18, 2012 2:51 AM<= br> >To: Justin Uberti
>Cc: Ravindran, Parthasarathi; rtcweb= @ietf.org; public-webrtc@w3.org=
>Subject: Re: [rtcweb] Single offer with multiple answer handling in JSE= P
>[was RE: New JSEP draft posted]
>
>
>I'm most interested in real world use cases which if they were bein= g
>done with SIP would result in multiple 200 being processed by the
>browser. I have not got my head around why this would be needed yet and=
>without the use cases I'm having a hard time deciding if there is a=
>problem or not.
>
>
>On Feb 16, 2012, at 7:35 PM, Justin Uberti wrote:
>
>> Agree it has not been addressed. I'm having some trouble under= standing
>the exact flows that we need to address here (multiple 2xx, multiple 18= x
>followed by 2xx, multiple 18x followed by multiple 2xx) but if I
>understand correctly your suggestion was:
>>
>> 1) allow a setRemoteDesc(SDP_ANSWER) to follow a
>> setRemoteDesc(SDP_ANSWER)
>> 2) document that in this case (multiple 2xx), the JS is responsibl= e
>for sending BYE to the previous answerer.
>>
>> which sounds totally reasonable to me.
>>
>> If this sounds good to you, would you mind sketching out a call fl= ow
>that I could include in the examples section?
>>
>> On Thu, Feb 16, 2012 at 2:11 AM, Ravindran, Parthasarathi
><pravindran@sonusnet.com<= /a>> wrote:
>> Cullen/Justin,
>>
>> Single offer with multiple answer open item is not addressed in -0= 2
>version of JSEP draft. Hope you first agree this as an open item in
>JSEP.
>>
>> Thanks
>> Partha
>>
>> >-----Original Message-----
>> >From: Ravindran, Parthasarathi
>> >Sent: Wednesday, February 15, 2012 2:43 PM
>> >To: 'Cullen Jennings'
>> >Cc: Justin Uberti; rtcweb@i= etf.org; public-webrtc@w3.org
>> >Subject: RE: [rtcweb] Single offer with multiple answer handli= ng in
>> >JSEP [was RE: New JSEP draft posted]
>> >
>> >Cullen,
>> >
>> >RFC3261 references for receiving multiple 2xx in UAC which doe= s not
>> >fork INVITE are as follows:
>> >
>> ><RFC quote>
>> >Sec 13.1 Para 3:
>> >
>> >Therefore, when multiple 2xx responses are received from diffe= rent
>> >remote UAs (because the INVITE forked), each 2xx establishes a=
>> >different dialog. =C2=A0All these dialogs are part of the same= call.
>> >
>> >Sec 13.2.2.4 2xx Responses
>> >
>> > =C2=A0 Multiple 2xx responses may arrive at the UAC for a sin= gle INVITE
>> > =C2=A0 request due to a forking proxy. =C2=A0Each response is= distinguished by
>> > =C2=A0 the tag parameter in the To header field, and each rep= resents a
>> > =C2=A0 distinct dialog, with a distinct dialog identifier. >> >
>> > =C2=A0 If, after acknowledging any 2xx response to an INVITE,= the UAC
>does
>> > =C2=A0 not want to continue with that dialog, then the UAC MU= ST terminate
>> > =C2=A0 the dialog by sending a BYE request as described in Se= ction 15.
>> ></RFC quote>
>> >
>> >As per the last statements, it is upto the SIP application to = decide
>> >which one of the final 2xx response has to be included within = the
>call.
>> >The usecase 3 is based on RFC3262 (PRACK) support wherein it i= s
>> >possible to receive multiple forked 18x with SDP followed by 2= xx with
>> >or without SDP and SIP 2xx response is not tied to offer/answe= r
>exchange.
>> >
>> >I have provided mobile to desktop as an example to justify the= last
>> >answer may be used in the offer in some JS application. As I >> >mentioned below, there is no need to restrict updating latest = answer
>> >for an offer in terms of API and protocol.
>> >
>> >Thanks
>> >Partha
>> >
>> >>-----Original Message-----
>> >>From: Cullen Jennings [mailto:fluffy@iii.ca]
>> >>Sent: Wednesday, February 15, 2012 1:31 PM
>> >>To: Ravindran, Parthasarathi
>> >>Cc: Justin Uberti; rtcw= eb@ietf.org; public-webrtc@w3.o= rg
>> >>Subject: Re: [rtcweb] Single offer with multiple answer ha= ndling in
>> >>JSEP [was RE: New JSEP draft posted]
>> >>
>> >>
>> >>I'm a bit lost on use case in SIP context - assuming t= hat the UAC
>> >>did not fork but that a proxy or B2BUA did the forking, it= seems
>> >>like the UAC should never receive more than one final resp= onse.
>> >>
>> >>In the case of moving from desktop to mobile, it seems lik= e that is
>> >>updating the stream and would use a call flow more like up= date
>> >>examples in the draft instead of trying to reuse some old = answer.
>> >>
>> >>
>> >>On Feb 14, 2012, at 11:24 , Ravindran, Parthasarathi wrote= :
>> >>
>> >>> Justin,
>> >>>
>> >>> Some of the usecases could be
>> >>> 1) =C2=A0 =C2=A0 =C2=A0The same user of a website sig= ned-in in the multiples
>devices
>> >>and acts as answerer, =C2=A0the session establishment requ= est to the
>> >>identity will alert all the signed-in devices and it is po= ssible
>> >>that multiple devices answer to the session. Here, user ma= y move
>> >>from one device
>> >>(mobile) to another device (desktop) within the session an= d wishes
>> >>to continue the session with the last answer. Please note = that
>> >>website is flexible to provide this service.
>> >>> 2) =C2=A0 =C2=A0 =C2=A0RFC 3261 SIP UA offer/answer h= andling w.r.t INVITE with
>SDP
>> >to
>> >>multiple 2xx with SDP handling scenario using JSEP
>> >>> 3) =C2=A0 =C2=A0 =C2=A0Another SIP usecase could be m= ultiple 18x responses with
>SDP
>> >>for INVITE with SDP and multiple 2xx responses without SDP= but order
>> >>within 18x and 200 are not same. Say 2xx of the second 18x= is
>> >>received as the first 2xx. Here, we need to know how secon= d 18x is
>> >>handled and also, the subsequent 2xx is handled.
>> >>>
>> >>> Of course, it is possible to build more usecases arou= nd this area.
>> >>> As
>> >>we made signaling outside the scope of WebRTC, it is upto = JS
>> >>application to decide the order in which offer/answer happ= ens. I'm
>> >>not relating offer/answer FSM with session establishment s= tate like
>> >>18x, 2xx but I'm interested in knowing browser media p= lane behavior
>> >>in different state of offer/answer handling by which JS ap= plication
>> >>behaves consistently in all browsers.
>> >>>
>> >>> Thanks
>> >>> Partha
>> >>>
>> >>>
>> >>> From: Justin Uberti [mailto:juberti@google.com]
>> >>> Sent: Tuesday, February 14, 2012 11:36 PM
>> >>> To: Ravindran, Parthasarathi
>> >>> Cc: rtcweb@ietf.or= g; public-webrtc@w3.org
>> >>> Subject: Re: Single offer with multiple answer handli= ng in JSEP
>> >>> [was
>> >>RE: [rtcweb] New JSEP draft posted]
>> >>>
>> >>> Partha,
>> >>>
>> >>> I need more information about the use case to provide= an accurate
>> >>response. As mentioned in my earlier mail, are both answer= s 2xx
>> >>responses?
>> >>>
>> >>> On Tue, Feb 14, 2012 at 12:17 PM, Ravindran, Parthasa= rathi
>> >><pravindran@= sonusnet.com> wrote:
>> >>> Hi Justin,
>> >>>
>> >>> In this mail thread, Let us define the behavior of mu= ltiple
>> >>> (atleast
>> >>two) answers for the single offer in WebRTC browser. =C2= =A0Now, Please
>> >>let me know your opinion for my below mail.
>> >>>
>> >>> Thanks
>> >>> Partha
>> >>>
>> >>> From: Justin Uberti [mailto:juberti@google.com]
>> >>> Sent: Tuesday, February 14, 2012 9:47 PM
>> >>>
>> >>> To: Ravindran, Parthasarathi
>> >>> Cc: rtcweb@ietf.or= g; public-webrtc@w3.org
>> >>> Subject: Re: Single offer with multiple answer handli= ng in JSEP
>> >>> [was
>> >>RE: [rtcweb] New JSEP draft posted]
>> >>>
>> >>>
>> >>>
>> >>> On Tue, Feb 14, 2012 at 6:39 AM, Ravindran, Parthasar= athi
>> >><pravindran@= sonusnet.com> wrote:
>> >>> Hi Justin,
>> >>>
>> >>> It will be good to mention in the JSEP draft =C2=A0th= at multiple
>> >>> answers
>> >>for single offer will not lead to RTP Mixing and WebRTC cl= ient acts
>> >>as RTP Endpoint.
>> >>>
>> >>> Failing the second Answer will be limiting the provis= ion in RFC
>> >>> 3264
>> >>offer/answer itself as RFC 3264 supports single offer with= multiple
>> >>answer. Also, it is better to define the behavior in API r= ather than
>> >>putting this scenario in the browser implementation specif= ic. In
>> >>simple scenarios (like alerting with one answer, connect w= ith second
>> >>answer), replacing the previous ANSWER will be expected be= havior.
>> >>This may not be desired behavior in case two connect respo= nses from
>> >>different WebRTC clients received with different answers = =C2=A0but there
>> >>is no other alternative solution possible without mixing.<= br> >> >>>
>> >>> Do you need to support 2 final answers, or would the = provisional
>> >>answer support provided via SDP_PRANSWER work for you?
>> >>>
>> >>> IMO, it is better to define it explicitly in JSEP tha= t "latest
>> >>> ANSWER
>> >>to the offer will replace the existing answer is the expec= ted
>> >>behavior ". Also, Please mentioned that JS applicatio= n is
>responsible for
>> >>discarding (terminating) previous ANSWER notification. =C2= =A0 Please let
>me
>> >>your opinion on this closure.
>> >>>
>> >>> Thanks
>> >>> Partha
>> >>>
>> >>> From: Justin Uberti [mailto:juberti@google.com]
>> >>> Sent: Tuesday, February 14, 2012 7:29 PM
>> >>> To: Ravindran, Parthasarathi
>> >>> Cc: rtcweb@ietf.or= g; public-webrtc@w3.org
>> >>> Subject: Re: Single offer with multiple answer handli= ng in JSEP
>> >>> [was
>> >>RE: [rtcweb] New JSEP draft posted]
>> >>>
>> >>> Regarding your previous mail, an ANSWER after an ANSW= ER would
>> >>> either
>> >>fail (if we wanted to simplify), or replace the previous A= NSWER
>> >>(essentially the same as if you had done setLocalDescripti= on(OFFER,
>> >>localDescription) followed by setRemoteDescription(ANSWER,= answer2).
>> >>>
>> >>> In no case would it mix the descriptions/media from b= oth answers.
>> >>>
>> >>> Other comments inline below.
>> >>>
>> >>> On Tue, Feb 14, 2012 at 1:24 AM, Ravindran, Parthasar= athi
>> >><pravindran@= sonusnet.com> wrote:
>> >>> Hi Justin,
>> >>>
>> >>> Adding to my earlier mail, In case answer2 SDP is upd= ated in
>> >>> offerer1
>> >>browser without notifying answerer1, then answer1 will con= tinue to
>> >>transmit RTP which may not be desired behavior. IMO, we ne= ed to
>> >>define this behavior clearly in offerer side. Some of the = possible
>> >>solutions are
>> >>>
>> >>> 1) =C2=A0 =C2=A0 =C2=A0offerer1 has to send atleast R= TCP BYE packets towards
>> >>answerer1 while accepting the answerer2 SDP.
>> >>>
>> >>> 2) =C2=A0 =C2=A0 =C2=A0Throw callback to clear answer= 1 SDP towards offererJS.
>> >>>
>> >>>
>> >>> The application which called setRemoteDescription twi= ce should
>> >>> have
>> >>the best idea about what is going on, and therefore is res= ponsible
>> >>for notifying answerer1 that its answer has been discarded= , if it
>> >>makes sense to do so. No callback should be needed here. >> >>>
>> >>>
>> >>> Please let me know your opinion here.
>> >>>
>> >>> Thanks
>> >>> Partha
>> >>>
>> >>> From: Ravindran, Parthasarathi
>> >>> Sent: Tuesday, February 14, 2012 12:07 AM
>> >>> To: 'Justin Uberti'; rtcweb@ietf.org; pub= lic-webrtc@w3.org
>> >>> Subject: Single offer with multiple answer handling i= n JSEP [was
>RE:
>> >>[rtcweb] New JSEP draft posted]
>> >>>
>> >>> Hi Justin,
>> >>>
>> >>> In the draft, it is not spelled out explicitly what i= s the
>> >>> expected
>> >>behavior in offerer browser in case multiple answer is rec= eived for
>> >>single offer. Offer/answer exchange in offerer is as follo= ws:
>> >>>
>> >>> OffererJS->OffererUA: var offer =3D pc.createOffer= (null);
>> >>> OffererJS->OffererUA: pc.setLocalDescription(SDP_O= FFER, offer);
>> >>> OffererJS->OffererUA: =C2=A0pc.setRemoteDescriptio= n(SDP_ANSWER,
>> >>> OffererJS->answer1);
>> >>> OffererUA->Answerer1UA: <medi= a>
>> >>> OffererJS->OffererUA: =C2=A0pc.setRemoteDescriptio= n(SDP_ANSWER,
>> >>> OffererJS->answer2);
>> >>> OffererUA->= ;Answerer?UA: <media>?
>> >>>
>> >>> My understanding is that "answer2" will upd= ate "answer1" in
>> >>> browser
>> >>and starting sending/receiving media towards answer2 media= IP and
>port.
>> >>Could you please explain the expected behavior in offerer = browser
>> >>whether it updates the media stream based on the last answ= er or
>> >>mixes both answerer.
>> >>>
>> >>> Thanks
>> >>> Partha
>> >>>
>> >>> From: rtcw= eb-bounces@ietf.org [mailto:= rtcweb-bounces@ietf.org] On
>> >>Behalf Of Justin Uberti
>> >>> Sent: Thursday, February 09, 2012 2:27 AM
>> >>> To: rtcweb@ietf.or= g; public-webrtc@w3.org
>> >>> Subject: [rtcweb] New JSEP draft posted
>> >>>
>> >>> Now available at http://www.ietf.org/id/draft-ube= rti-rtcweb-jsep-
>> >>01.txt
>> >>>
>> >>> Includes changes based on implementation feedback, an= d I believe
>> >>> it
>> >>addresses most of the concerns raised in last week's i= nterim
>meetings:
>> >>> - Initial documentation provided for each API call, a= nd what state
>> >>changes it causes
>> >>> - More examples, including a complete basic sample ap= plication
>> >>> - Simplified approach to trickle candidate handling >> >>> - Resolved concerns about how to separate SDP attribu= tes into
>> >>> media /
>> >>transport
>> >>> - Provided encapsulation for SDP blobs and ICE candid= ate lines, in
>> >>> the
>> >>event we want to change encodings or provide helper functi= ons for JS
>> >>> - Provided mechanism for limiting candidates to TURN-= only
>> >>> - Resolved several implementation issues
>> >>>
>> >>> I have not yet addressed the non-overlapping codec co= ncern
>> >>> mentioned
>> >>in the interim meeting. I think there are ways of handling= this
>> >>either in the application or the implementation, but I wan= ted to get
>> >>this -01 out first for feedback.
>> >>>
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> rtcweb mailing list
>> >>> rtcweb@ietf.org
>> >>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>


--00248c6a7a8e82985404b9722601-- From juberti@google.com Mon Feb 20 20:54: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 02ACD21F852D for ; Mon, 20 Feb 2012 20:54:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.773 X-Spam-Level: X-Spam-Status: No, score=-102.773 tagged_above=-999 required=5 tests=[AWL=0.203, 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 IC6loScazYJM for ; Mon, 20 Feb 2012 20:54:50 -0800 (PST) Received: from mail-qw0-f49.google.com (mail-qw0-f49.google.com [209.85.216.49]) by ietfa.amsl.com (Postfix) with ESMTP id CB03F21F852A for ; Mon, 20 Feb 2012 20:54:49 -0800 (PST) Received: by qadc14 with SMTP id c14so6777556qad.15 for ; Mon, 20 Feb 2012 20:54:48 -0800 (PST) Received-SPF: pass (google.com: domain of juberti@google.com designates 10.229.78.89 as permitted sender) client-ip=10.229.78.89; Authentication-Results: mr.google.com; spf=pass (google.com: domain of juberti@google.com designates 10.229.78.89 as permitted sender) smtp.mail=juberti@google.com; dkim=pass header.i=juberti@google.com Received: from mr.google.com ([10.229.78.89]) by 10.229.78.89 with SMTP id j25mr18428042qck.46.1329800088812 (num_hops = 1); Mon, 20 Feb 2012 20:54:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=AievPTVHyQ2vCgWOoFW3XYPWsGyFkTwv38LG1plENcw=; b=0blifv9tXS3RJHWqdYPOczSvJYdo2HcSWauNZEFGndHfOsOU3scq6xmObZLHQtekKs 5UW3KZTpRvdu1VqvXYG2K3WikrfMg+O0bUZ4rz2/RwOWBtZ8MQIC9BeT4jXFP8B3xhxS pDv3mGoCxYviUO0G4HyIiT7vO2oZU5EsuVie8= Received: by 10.229.78.89 with SMTP id j25mr15586937qck.46.1329800088670; Mon, 20 Feb 2012 20:54:48 -0800 (PST) Received: by 10.229.78.89 with SMTP id j25mr15586896qck.46.1329800087289; Mon, 20 Feb 2012 20:54:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.29.195 with HTTP; Mon, 20 Feb 2012 20:54:27 -0800 (PST) In-Reply-To: References: From: Justin Uberti Date: Mon, 20 Feb 2012 23:54:27 -0500 Message-ID: To: Bernard Aboba Content-Type: multipart/alternative; boundary=00235429d374d33f7404b9723531 X-System-Of-Record: true X-Gm-Message-State: ALoCoQn7l9rmpofSNjMxrGYpZ2ErefwLBRAVde8CBOjeF99HnBQoVmv4inP2YXOjVfvIvG3Tyk8k2XD1mOV20sVW9E/6Wuw7ogOPspfdDVySBMdyxSTORBLoWPKXhbN6lTa3qwKQs1WUx1RTET9bxz56cE5O4fIG5g== Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Section 5.2.1 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, 21 Feb 2012 04:54:51 -0000 --00235429d374d33f7404b9723531 Content-Type: text/plain; charset=UTF-8 On Fri, Feb 17, 2012 at 10:48 PM, Bernard Aboba wrote: > Other (related) questions > > Section 6.1.3: > > "Session descriptions generated by createAnswer must be immediately usable > by setRemoteDescription; " > > setRemoteDescription(SDP_ANSWER, answer) called by the offerer (Section > 5.3.1), but on the Answerer, it is setLocalDescription(SDP_ANSWER, answer) > (Section 5.2.5). Which side is the above sentence referring to? > This should have said setLocalDescription. > > Section 6.1.6: > > "Changes to the state of media transmission will only occur when a final > answer is successfully applied.". > > Setting PRANSWER aside, is this statement only valid for the offerer? Or > does it imply that setRemoteDescription is to be called with an SDP_ANSWER > on the Answerer? > The statement by itself is true for either side, but setRemoteDescription specifically will only be called with a final answer by the offerer. > > > Some nits: > > Page 6: s/it provides/provides/ > Page 16: duplicate 3rd paragraph > Page 17: duplicate 3rd paragraph > Thanks for pointing these out. I'm away on vacation this week, but will incorporate these comments when I get back. > > > > On Feb 17, 2012, at 17:46, "Bernard Aboba" > wrote: > > Section 5.2.1 in the JSEP-02 draft raised a question: > > "This step will also cause encoder resources to be allocated, based on the > codecs specified in |offer|." > > [BA] Should the answerer allocate encoding resources based on the codecs > specified in the answer, as opposed to the offer? > > setRemoteDescription(SDP_OFFER, offer) sets the SRTP keys used to receive, > then setLocalDescription(SDP_ANSWER, answer) > causes transmission of media by the answerer. > > _______________________________________________ > 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 > > --00235429d374d33f7404b9723531 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Feb 17, 2012 at 10:48 PM, Bernard Ab= oba <bern= ard_aboba@hotmail.com> wrote:
Other (related) questions

Section 6.1.3:

"Session descriptions ge= nerated by createAnswer must be immediately usable by setRemoteDescription;= "

setRemoteDescription(SDP_ANSWER, answer) called by the = offerer (Section 5.3.1), but on the Answerer, it is setLocalDescription(SDP= _ANSWER, answer) (Section 5.2.5). =C2=A0Which side is the above sentence re= ferring to?

This should have said setLocalDescri= ption.=C2=A0
<= div>
Section 6.1.6:

"Changes to the sta= te of media transmission will only occur when a final answer is successfull= y applied.". =C2=A0

Setting PRANSWER aside, i= s this statement only valid for the offerer? Or does it imply that setRemot= eDescription is to be called with an SDP_ANSWER on the Answerer?

The statement by itself is true for = either side, but setRemoteDescription specifically will only be called with= a final answer by the offerer.


Some nits:

Page 6: s/it provides/provides/
Page 16: dup= licate 3rd paragraph
Page 17: duplicate 3rd paragraph

Thanks for pointing these out. I'= ;m away on vacation this week, but will incorporate these comments when I g= et back.


On Feb 17, 2012, at 17:46, "Bernard Aboba" <bernard_aboba@hotmail.com= > wrote:

Section 5.2.1 in the JSEP-02 draft raised a question:

"This ste= p will also cause encoder resources to be allocated, based on the codecs sp= ecified in |offer|."

[BA] Should the answerer allocate encoding= resources based on the codecs specified in the answer, as opposed to the o= ffer?

setRemoteDescription(SDP_OFFER, offer) sets the SRTP keys used to recei= ve, then setLocalDescription(SDP_ANSWER, answer)
causes transmission of = media by the answerer.
_______= ________________________________________
rtcweb mailing lis= t
rtcw= eb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

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


--00235429d374d33f7404b9723531-- From pravindran@sonusnet.com Mon Feb 20 22:58: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 7DCC721F85EA for ; Mon, 20 Feb 2012 22:58:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[AWL=-0.289, BAYES_00=-2.599, J_CHICKENPOX_65=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 cHqoTBGzH0kI for ; Mon, 20 Feb 2012 22:58:10 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 69AFB21F85DD for ; Mon, 20 Feb 2012 22:58:10 -0800 (PST) Received: from sonusmail05.sonusnet.com (sonusmail05.sonusnet.com [10.128.32.155]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q1L6wuxR010383; Tue, 21 Feb 2012 01:58:56 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Feb 2012 01:58:08 -0500 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Feb 2012 12:28:21 +0530 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; Tue, 21 Feb 2012 12:28:20 +0530 From: "Ravindran, Parthasarathi" To: Randell Jesup , "rtcweb@ietf.org" , "public-webrtc@w3.org" Thread-Topic: [rtcweb] JSEP-02: New offer and answer to previous offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case] Thread-Index: AQHM8AqE+28vByK84kKxG08H/gll95ZF3BIAgAAASYCAAASXgIAAGTuAgADuMEA= Date: Tue, 21 Feb 2012 06:58:19 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E040FFE@inba-mail01.sonusnet.com> References: <7F2072F1E0DE894DA4B517B93C6A05852C3D31BA37@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C3D31BA3A@ESESSCMS0356.eemea.ericsson.se> <4F42C2C7.3060802@jesup.org> In-Reply-To: <4F42C2C7.3060802@jesup.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.70] Content-Type: multipart/mixed; boundary="_002_387F9047F55E8C42850AD6B3A7A03C6C0E040FFEinbamail01sonus_" MIME-Version: 1.0 X-OriginalArrivalTime: 21 Feb 2012 06:58:21.0315 (UTC) FILETIME=[32997530:01CCF066] Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case] 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, 21 Feb 2012 06:58:11 -0000 --_002_387F9047F55E8C42850AD6B3A7A03C6C0E040FFEinbamail01sonus_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Randell, It is possible to implement parallel forking by keeping only one answer act= ive in the offerer side at the given time. I attached one of the example "1= 8x with SDP and 2xx with different SDP" for your reference which will map t= o serial forking. Please let me know your concern about ICE interaction con= cern here. I'll send multiple 18x with SDP and one 2xx with SDP response JSEP example = using UPDATE O/A mechanism ASAP for clarity on parallel forking (assumption= : multiple answer for single offer is supported in JSEP). Thanks Partha >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of Randell Jesup >Sent: Tuesday, February 21, 2012 3:32 AM >To: rtcweb@ietf.org; public-webrtc@w3.org >Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous offer >[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] > >On 2/20/2012 3:31 PM, Roman Shpount wrote: >> Not to beat this horse to death, but why is it "suggested not to have >> parallel forking"? WebRTC intorduces additional restrictions on RTP >> stream (remote media sources and SSRCs are known in advance) that make >> parallel forking implementation trivial. Only thing that is missing is >> some way to clone the PeerConnection in the API. > >Right; parallel forking has uses. > >We've talked about this, but not for a while. One way to implement it >would be to on each forked answer clone the state of the PeerConnection >as it was with any previous answer removed. However, I'm concerned >about how this will interact with the ICE, etc stuff. Someone want to >throw out a suggestion? Cullen, Justin - how *should*/*could* forking >work within JSEP? > > >Aside on uses of forking: >I can see some additional interesting uses for parallel forking, >especially in non-phone-like usecases (games among others). The server >(or another participant) could hold open an OFFER in order to forward it >to any potential new partners. This might apply to a conference call as >well if there's a peer-2-peer aspect (mesh, partial-mesh, etc) to it. > >Think in a game or 2nd-life-type-sim, where you're automatically in a >voice chat with anyone within hearing range, and those voice chats are >done p2p by forking each player's original offer to the server, and >forwarding it (forking it) to the new user, who would answer and they'd >be in a call. > >If you wanted to get really fancy, you could even do some of the >negotiation in the server and rephrase each offer as an answer to the >other side, leading to a 1/2-RTT-to-the-server setup time (more-or-less: > >player 1 server player 2 >------------------------------------------------------------ >| | | >|--> Offer 1 ---------------->| | >| |<---------- Offer 2 <----| >| | | >... > Server decides they should talk >| | | >|<-- Answer(Offer 2) <--------|-----> Answer(Offer 1)-->| >|<------------------------- media --------------------->| > >Even if this is initiated by a player, there are equivalent graphs that >use 1/2 RTT (through the server to other player) to set up channels. > >I should note however that ICE overhead may well swamp this fancy setup >and it may be over-reaching, but each 1/2 RTT removed is significant, so >there may be uses. > >> _____________ >> Roman Shpount >> >> >> On Mon, Feb 20, 2012 at 3:14 PM, Christer Holmberg >> > > >> wrote: >> >> >> Hi, >> >> Just to clarify: the new offer is for the same "session" as the >> previous offer, and is supposed to replace the previous offer. >> >> The browser can of course send a just-audio offer somewhere, and a >> just-video offer somewhere else, but would those even be >associated >> with the same PeerConnection? I thought we wanted only one >> offer/answer, which is the reason it has been suggested e.g. not >to >> support paralell forking in the browser. >> >> Regards, >> >> Christer >> ________________________________________ >> From: I=F1aki Baz Castillo [ibc@aliax.net ] >> Sent: Monday, February 20, 2012 10:13 PM >> To: Christer Holmberg >> Cc: Justin Uberti; rtcweb@ietf.org ; >> public-webrtc@w3.org >> Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous >> offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case] >> >> 2012/2/20 Christer Holmberg > >: >> > Q1. When the JS app requests the new offer (o-2), I assume all >> resources etc associated with o-1 will be released (unless they >are >> also needed for o-2, that is). >> >> Does it mean that the browser is just capable of having *one* >> multimedia session at the same time? Well, in SIP world this >typically >> means putting on-hold the previous call so, indeed, resources >would be >> released. >> >> But, why couldn't the browser send a just-audio offer somewhere >and a >> just-video offer to other destination at the same time? >> >> -- >> I=F1aki Baz Castillo >> > >> _______________________________________________ >> 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 > > >-- >Randell Jesup >randell-ietf@jesup.org >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb --_002_387F9047F55E8C42850AD6B3A7A03C6C0E040FFEinbamail01sonus_ Content-Type: text/plain; name="18x with SDP and 2xx with different SDP.txt" Content-Description: 18x with SDP and 2xx with different SDP.txt Content-Disposition: attachment; filename="18x with SDP and 2xx with different SDP.txt"; size=1486; creation-date="Sun, 19 Feb 2012 18:11:39 GMT"; modification-date="Sun, 19 Feb 2012 18:24:41 GMT" Content-Transfer-Encoding: base64 SGFuZGxpbmcgMTh4IHdpdGggU0RQIGFuZCAyeHggd2l0aG91dCBTRFAsIHVzaW5nIFNJUA0KDQog ICBUaGlzIGV4YW1wbGUgZGVtb25zdHJhdGVzIGhvdyAxOHggd2l0aCBTRFAgY291bGQgYmUgaGFu ZGxlZDsgZm9yDQogICBzaW1wbGljaXR5LCBvbmx5IHRoZSBvZmZlcmVyIHNpZGUgb2YgdGhlIGNh bGwgaXMgc2hvd24uDQoNCiAgIC8vIENhbGwgaXMgaW5pdGlhdGVkIHRvd2FyZCBBbnN3ZXJlcg0K ICAgT2ZmZXJlckpTLT5PZmZlcmVyVUE6ICAgcGMgPSBuZXcgUGVlckNvbm5lY3Rpb24oKTsNCiAg IE9mZmVyZXJKUy0+T2ZmZXJlclVBOiAgIHBjLmFkZFN0cmVhbShsb2NhbFN0cmVhbSwgbnVsbCk7 DQogICBPZmZlcmVySlMtPk9mZmVyZXJVQTogICBwYy5zdGFydEljZSgpOw0KICAgT2ZmZXJlclVB LT5PZmZlcmVySlM6ICAgaWNlQ2FsbGJhY2soY2FuZGlkYXRlLCBmYWxzZSk7DQogICBPZmZlcmVy SlMtPk9mZmVyZXJVQTogICBvZmZlciA9IHBjLmNyZWF0ZU9mZmVyKG51bGwpOw0KICAgT2ZmZXJl ckpTLT5PZmZlcmVyVUE6ICAgcGMuc2V0TG9jYWxEZXNjcmlwdGlvbihTRFBfT0ZGRVIsIG9mZmVy KTsNCiAgIE9mZmVyZXJKUzogICAgICAgICAgICAgIHNpcCA9IGNyZWF0ZUludml0ZShvZmZlcik7 DQogICBPZmZlcmVySlMtPkFuc3dlcmVySlM6ICBTSVAgSU5WSVRFIHcvIFNEUA0KDQogICAvLyAx ODAgUmluZ2luZyBpcyByZWNlaXZlZCBieSBvZmZlcmVyLCB3L1NEUDENCiAgIE9mZmVyZXJKUzog ICAgICAgICAgICAgIGFuc3dlcjEgPSBwYXJzZVJlc3BvbnNlKHNpcCk7DQogICBPZmZlcmVySlMt Pk9mZmVyZXJVQTogICBwYy5zZXRSZW1vdGVEZXNjcmlwdGlvbihTRFBfQU5TV0VSLCBhbnN3ZXIx KTsNCiAgIE9mZmVyZXJVQS0+T2ZmZXJlckpTOiAgIG9uYWRkc3RyZWFtKHJlbW90ZVN0cmVhbSk7 DQoNCiAgIC8vIElDRSBDb21wbGV0ZXMgKGF0IE9mZmVyZXIpDQogICBPZmZlcmVyVUEtPk9mZmVy ZXJKUzogICBvbm9wZW4oKTsNCiAgIE9mZmVyZXJKUy0+QW5zd2VyZXIxSlM6ICB7InR5cGUiOiJP SyIgfQ0KICAgT2ZmZXJlclVBLT5BbnN3ZXJlcjFVQTogIE1lZGlhDQoNCiAgIC8vIDIwMCBPSyBh cnJpdmVzIGF0IE9mZmVyZXIsIHcvc2RwMiBhbmQgZGlmZmVyZW50IFRPIHRhZw0KICAgT2ZmZXJl ckpTOiAgICAgICAgICAgICAgYW5zd2VyMiA9IHBhcnNlUmVzcG9uc2Uoc2lwKTsNCiAgIE9mZmVy ZXJKUy0+T2ZmZXJlclVBOiAgIHBjLnNldFJlbW90ZURlc2NyaXB0aW9uKFNEUF9BTlNXRVIsIGFu c3dlcjIpOw0KICAgT2ZmZXJlckpTLT5BbnN3ZXJlcjJKUzogIEFDSw0KICAgT2ZmZXJlckpTLT5B bnN3ZXJlcjFKUzogIEJZRQ0KDQoNCiAgIC8vIElDRSBDb21wbGV0ZXMgKGF0IE9mZmVyZXIpDQog ICBPZmZlcmVyVUEtPk9mZmVyZXJKUzogICBvbm9wZW4oKTsNCiAgIE9mZmVyZXJKUy0+QW5zd2Vy ZXIySlM6ICB7InR5cGUiOiJPSyIgfQ0KICAgT2ZmZXJlclVBLT5BbnN3ZXJlcjJVQTogIE1lZGlh DQoNCg== --_002_387F9047F55E8C42850AD6B3A7A03C6C0E040FFEinbamail01sonus_-- From richard.ejzak@alcatel-lucent.com Tue Feb 21 06:35:03 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 33CBC21F8839 for ; Tue, 21 Feb 2012 06:35:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_65=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 u45xY92eNckx for ; Tue, 21 Feb 2012 06:35:02 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0E0DD21F87A8 for ; Tue, 21 Feb 2012 06:35:01 -0800 (PST) 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 q1LEYvdv000196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 Feb 2012 08:34:57 -0600 (CST) 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 q1LEYuVV001436 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 21 Feb 2012 08:34:56 -0600 Received: from USNAVSXCHMBSA1.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Tue, 21 Feb 2012 08:34:56 -0600 From: "Ejzak, Richard P (Richard)" To: "Ravindran, Parthasarathi" , "rtcweb@ietf.org" , "public-webrtc@w3.org" Date: Tue, 21 Feb 2012 08:34:55 -0600 Thread-Topic: [rtcweb] JSEP-02: New offer and answer to previous offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case] Thread-Index: AQHM8AqE+28vByK84kKxG08H/gll95ZF3BIAgAAASYCAAASXgIAAGTuAgADuMECAAH0N0A== Message-ID: <6F428EFD2B8C2F49A2FB1317291A76C11355D49C4E@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> References: <7F2072F1E0DE894DA4B517B93C6A05852C3D31BA37@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C3D31BA3A@ESESSCMS0356.eemea.ericsson.se> <4F42C2C7.3060802@jesup.org> <387F9047F55E8C42850AD6B3A7A03C6C0E040FFE@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E040FFE@inba-mail01.sonusnet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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] JSEP-02: New offer and answer to previous offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case] 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, 21 Feb 2012 14:35:03 -0000 Hi Partha, Regarding my earlier email (this earlier email was not distributed on the w= ebrtc list), I do not dispute that forking must be supported by all SIP end= points. Let me rephrase my earlier questions in light of your latest call = flow. Looking at your call flow, I see that you treat the case of multiple answer= s from the same endpoint as a serial forking case (or do I misunderstand yo= ur intent?). How do you determine that this is a special type of serial fo= rking and not a parallel forking case? We have at least three use cases fo= r multiple ANSWER and it would be helpful to see how they can be handled an= d distinguished in SIP signaling. =20 Also, PRANSWER as currently defined seems to have no analog in SIP. Is thi= s also your understanding? I don't understand your statement that "It is possible to implement paralle= l forking by keeping only one answer active in the offerer side at the give= n time". It would appear that an implementation of parallel forking would = need to keep the last answer from each dialog active. Please explain. I look forward to your next call flow. Richard -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Ravindran, Parthasarathi Sent: Tuesday, February 21, 2012 12:58 AM To: Randell Jesup; rtcweb@ietf.org; public-webrtc@w3.org Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous offer [was:= JSEP-02: SDP_PRANSWER and FEDEX use-case] Randell, It is possible to implement parallel forking by keeping only one answer act= ive in the offerer side at the given time. I attached one of the example "1= 8x with SDP and 2xx with different SDP" for your reference which will map t= o serial forking. Please let me know your concern about ICE interaction con= cern here. I'll send multiple 18x with SDP and one 2xx with SDP response JSEP example = using UPDATE O/A mechanism ASAP for clarity on parallel forking (assumption= : multiple answer for single offer is supported in JSEP). Thanks Partha >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of Randell Jesup >Sent: Tuesday, February 21, 2012 3:32 AM >To: rtcweb@ietf.org; public-webrtc@w3.org >Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous offer >[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] > >On 2/20/2012 3:31 PM, Roman Shpount wrote: >> Not to beat this horse to death, but why is it "suggested not to have >> parallel forking"? WebRTC intorduces additional restrictions on RTP >> stream (remote media sources and SSRCs are known in advance) that make >> parallel forking implementation trivial. Only thing that is missing is >> some way to clone the PeerConnection in the API. > >Right; parallel forking has uses. > >We've talked about this, but not for a while. One way to implement it >would be to on each forked answer clone the state of the PeerConnection >as it was with any previous answer removed. However, I'm concerned >about how this will interact with the ICE, etc stuff. Someone want to >throw out a suggestion? Cullen, Justin - how *should*/*could* forking >work within JSEP? > > >Aside on uses of forking: >I can see some additional interesting uses for parallel forking, >especially in non-phone-like usecases (games among others). The server >(or another participant) could hold open an OFFER in order to forward it >to any potential new partners. This might apply to a conference call as >well if there's a peer-2-peer aspect (mesh, partial-mesh, etc) to it. > >Think in a game or 2nd-life-type-sim, where you're automatically in a >voice chat with anyone within hearing range, and those voice chats are >done p2p by forking each player's original offer to the server, and >forwarding it (forking it) to the new user, who would answer and they'd >be in a call. > >If you wanted to get really fancy, you could even do some of the >negotiation in the server and rephrase each offer as an answer to the >other side, leading to a 1/2-RTT-to-the-server setup time (more-or-less: > >player 1 server player 2 >------------------------------------------------------------ >| | | >|--> Offer 1 ---------------->| | >| |<---------- Offer 2 <----| >| | | >... > Server decides they should talk >| | | >|<-- Answer(Offer 2) <--------|-----> Answer(Offer 1)-->| >|<------------------------- media --------------------->| > >Even if this is initiated by a player, there are equivalent graphs that >use 1/2 RTT (through the server to other player) to set up channels. > >I should note however that ICE overhead may well swamp this fancy setup >and it may be over-reaching, but each 1/2 RTT removed is significant, so >there may be uses. > >> _____________ >> Roman Shpount >> >> >> On Mon, Feb 20, 2012 at 3:14 PM, Christer Holmberg >> > > >> wrote: >> >> >> Hi, >> >> Just to clarify: the new offer is for the same "session" as the >> previous offer, and is supposed to replace the previous offer. >> >> The browser can of course send a just-audio offer somewhere, and a >> just-video offer somewhere else, but would those even be >associated >> with the same PeerConnection? I thought we wanted only one >> offer/answer, which is the reason it has been suggested e.g. not >to >> support paralell forking in the browser. >> >> Regards, >> >> Christer >> ________________________________________ >> From: I=F1aki Baz Castillo [ibc@aliax.net ] >> Sent: Monday, February 20, 2012 10:13 PM >> To: Christer Holmberg >> Cc: Justin Uberti; rtcweb@ietf.org ; >> public-webrtc@w3.org >> Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous >> offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case] >> >> 2012/2/20 Christer Holmberg > >: >> > Q1. When the JS app requests the new offer (o-2), I assume all >> resources etc associated with o-1 will be released (unless they >are >> also needed for o-2, that is). >> >> Does it mean that the browser is just capable of having *one* >> multimedia session at the same time? Well, in SIP world this >typically >> means putting on-hold the previous call so, indeed, resources >would be >> released. >> >> But, why couldn't the browser send a just-audio offer somewhere >and a >> just-video offer to other destination at the same time? >> >> -- >> I=F1aki Baz Castillo >> > >> _______________________________________________ >> 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 > > >-- >Randell Jesup >randell-ietf@jesup.org >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From richard.ejzak@alcatel-lucent.com Tue Feb 21 08:52: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 28DED21F8873 for ; Tue, 21 Feb 2012 08:52:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, GB_SUMOF=5, 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 I9kARh3BYL2z for ; Tue, 21 Feb 2012 08:52:27 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id E231121F8843 for ; Tue, 21 Feb 2012 08:52:20 -0800 (PST) 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 q1LGqFLw004467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 21 Feb 2012 10:52:16 -0600 (CST) 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 q1LGqF4Z009297 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 21 Feb 2012 10:52:15 -0600 Received: from USNAVSXCHMBSA1.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Tue, 21 Feb 2012 10:52:15 -0600 From: "Ejzak, Richard P (Richard)" To: "rtcweb@ietf.org" Date: Tue, 21 Feb 2012 10:52:13 -0600 Thread-Topic: [rtcweb] Consensus call on JSEP/ROAP Thread-Index: Aczl1omYA1G2uq/ZRSekmPaGq8QmqAK2BHKg Message-ID: <6F428EFD2B8C2F49A2FB1317291A76C11355D49DF5@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> 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 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] Consensus call on JSEP/ROAP 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, 21 Feb 2012 16:52:32 -0000 Hi All, I would like to point out that if you rephrase the question to ask "who pre= fers to base subsequent work on RFC 3264 semantics?", then you would need t= o combine positions 2 and 4, and you would get a vote of 28 (the position 3= votes) for a new semantic model (requiring significant new work on SDP) ag= ainst 21 (the sum of votes for positions 2 and 4) for RFC 3264 semantics. So while I do not object to using JSEP as a basis for further work, it seem= s that the group is far less certain about the on-the-wire semantics to be = associated with it. My preference is to focus on RFC 3264 semantics (notin= g that the low level of the API would still allow considerable flexibility = to support other signaling protocols). My key concern is to have clear rul= es (based on common semantics) for interworking media/transport negotiation= procedures between different on-the-wire protocols to avoid potential inte= rop problems. =20 In particular, at this point in the discussion, I do not see the value of a= llowing multiple open OFFERs within a dialog (which have acknowledged probl= ems), multiple ANSWERs within a dialog, or PRANSWERs, none of which exist i= n RFC 3264. I propose that the group first decide whether to use JSEP as a basis for fu= rther work and in subsequent step(s) decide whether and how to go beyond RF= C 3264 semantics. I see this proposal as simply a clarification of the mea= ning of position 3. Richard Ejzak -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Ted Hardie Sent: Tuesday, February 07, 2012 2:25 PM To: rtcweb@ietf.org Subject: [rtcweb] Consensus call on JSEP/ROAP During the interim meeting, the attendees discussed the JSEP and ROAP proposals. The chairs also asked the working group to consider whether they might be successfully merged. Because of audio difficulties, there is no recording available. The jabber logs contain a transcription of the discussion by Bernard Aboba and can be found here: http://www.ietf.org/jabber/logs/rtcweb/2012-01-31.html. At the end of the discussion, the chairs asked the attendees to indicate their preferences by standing for one of four positions, which wer= e listed prior to the question being called. The positions were: 1--Don't care whether ROAP or JSEP is the input document for further work in this area 2---Prefer ROAP be the input document for further work 3--Prefer JSEP be the input document for further work 4--Prefer to merge the docs, limiting JSEP to RFC 3264 offer/answer semanti= cs. The results were: 1=3D9 in room, none in jabber 2=3D11 in room, 2 in jabber 3=3D25 in room, 3 in jabber 4=3D8 in room, none in jabber. Because JSEP supports more than one model of negotiation, choosing 3 is a reversal from previous working group consensus to limit work to the offer/answer model. The chairs are now calling for consensus of the working group on this point. Working group participants who were not present at the interim, please review the input documents if you not have yet done so, and forward your comments to the list. All working group participants are asked to make their points on this topic by February 22nd, so that we have timely input prior to the document deadline for Paris. thanks, Ted Hardie for the Chairs _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From caryfitz@employees.org Tue Feb 21 12: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 97D8521F84EF for ; Tue, 21 Feb 2012 12:13:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.402 X-Spam-Level: ** X-Spam-Status: No, score=2.402 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_SUMOF=5, 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 IE1ZT9dkC7P6 for ; Tue, 21 Feb 2012 12:13:47 -0800 (PST) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id BA52921E807D for ; Tue, 21 Feb 2012 12:13:46 -0800 (PST) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id 3A0DA5E25; Tue, 21 Feb 2012 12:13:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=ClbBD/w/2t1bVCSllXHAz+gJ8Pk=; b= X04qx4nm3p8+KNJpypefKDh1zg6pRtlaU5NYBvqJjpg3sbx8XHAyEBh3LnwU6gG0 JPCCE0WLfPtQ35bhaq+L2EAgvt9gmSVOaKy27oCDj4GNp1wMYXvWkRccaUIlkQEh PtI28XCIkW+i6nxmCTCoD5CpQMqvsQE2bfYP03OspEQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=Cp1c3Ys0YUPVD+Sct67KKINvx8 3DfIspC9VekgeMV/7NLy+Ex0v4ZVybyJvf6dF15qqA9MqQLX47rIQnsn631E8L0c f757+bRRqpiV7oKDU158BW76gOmIaiiUsXwKdiSVQWPraSyieAE9DBcnivakGgV9 7fEH7ALYn2AJ+U0bU= Received: from [135.11.40.225] (unknown [135.11.40.225]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: caryfitz) by banjo.employees.org (Postfix) with ESMTPSA id 0DBEB5DB4; Tue, 21 Feb 2012 12:13:42 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_E2E8419F-47C7-4B1C-8ABF-0198B108FABE" From: Cary W FitzGerald In-Reply-To: <6F428EFD2B8C2F49A2FB1317291A76C11355D49DF5@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> Date: Tue, 21 Feb 2012 12:13:32 -0800 Message-Id: <005BC7E2-88EE-4D8F-8AEA-4614D39A6DC6@employees.org> References: <6F428EFD2B8C2F49A2FB1317291A76C11355D49DF5@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> To: "Ejzak, Richard P (Richard)" X-Mailer: Apple Mail (2.1251.1) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consensus call on JSEP/ROAP 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, 21 Feb 2012 20:13:51 -0000 --Apple-Mail=_E2E8419F-47C7-4B1C-8ABF-0198B108FABE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This is partially inevitable. For WebRTC applications that interact = with SIP gateways, the WebRTC application can't signal anything that = 3264 won't allow, since the gateway's side won't be able to deal with = it. The original architecture document = http://tools.ietf.org/html/draft-ietf-rtcweb-overview-02 proposes a RTC = trapezoid and any well-behaved trapezoid needs to consider the SIP case = and therefore 3264. There is another important case, which is when the trapezoid degenerates = into a triangle. This is the case where the web server controls both = sides of the conversation (e.g. connecting to an attendant at = www.ftd.com without any intervening PBX/switch/traditional contact = center). Since there is no PSTN GW to contend with, it's not necessary = to obey the gateway's rules. In this case, the server presumably knows = what it's doing, so it's probably a bug if it trips itself up. There is potentially a third case, which is where the trapezoid is = maintained, and the servers are communicating with some-protocol-not-SIP = that doesn't need to abide by 3264 (which excludes H.323), but are not = smart enough to coordinate media between themselves, but this doesn't = seem very important. I could be wrong about that, but I don't see the = practical use case. Cary. On Feb 21, 2012, at 8:52 AM, Ejzak, Richard P (Richard) wrote: > Hi All, > I would like to point out that if you rephrase the question to ask = "who prefers to base subsequent work on RFC 3264 semantics?", then you = would need to combine positions 2 and 4, and you would get a vote of 28 = (the position 3 votes) for a new semantic model (requiring significant = new work on SDP) against 21 (the sum of votes for positions 2 and 4) for = RFC 3264 semantics. >=20 > So while I do not object to using JSEP as a basis for further work, it = seems that the group is far less certain about the on-the-wire semantics = to be associated with it. My preference is to focus on RFC 3264 = semantics (noting that the low level of the API would still allow = considerable flexibility to support other signaling protocols). My key = concern is to have clear rules (based on common semantics) for = interworking media/transport negotiation procedures between different = on-the-wire protocols to avoid potential interop problems. =20 >=20 > In particular, at this point in the discussion, I do not see the value = of allowing multiple open OFFERs within a dialog (which have = acknowledged problems), multiple ANSWERs within a dialog, or PRANSWERs, = none of which exist in RFC 3264. >=20 > I propose that the group first decide whether to use JSEP as a basis = for further work and in subsequent step(s) decide whether and how to go = beyond RFC 3264 semantics. I see this proposal as simply a = clarification of the meaning of position 3. >=20 > Richard Ejzak >=20 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On = Behalf Of Ted Hardie > Sent: Tuesday, February 07, 2012 2:25 PM > To: rtcweb@ietf.org > Subject: [rtcweb] Consensus call on JSEP/ROAP >=20 > During the interim meeting, the attendees discussed the JSEP and ROAP > proposals. The chairs also asked the working group to consider > whether they might be successfully merged. Because of audio = difficulties, > there is no recording available. The jabber logs contain > a transcription of the discussion by Bernard Aboba and can be found > here: http://www.ietf.org/jabber/logs/rtcweb/2012-01-31.html. >=20 > At the end of the discussion, the chairs asked the attendees to > indicate their preferences by standing for one of four positions, = which were > listed prior to the question being called. The positions were: >=20 > 1--Don't care whether ROAP or JSEP is the input document for further > work in this area >=20 > 2---Prefer ROAP be the input document for further work >=20 > 3--Prefer JSEP be the input document for further work >=20 > 4--Prefer to merge the docs, limiting JSEP to RFC 3264 offer/answer = semantics. >=20 > The results were: 1=3D9 in room, none in jabber > 2=3D11 in room, 2 in jabber > 3=3D25 in room, 3 in jabber > 4=3D8 in room, none in jabber. >=20 > Because JSEP supports more than one model of negotiation, choosing 3 > is a reversal from previous working group consensus to limit work to > the offer/answer model. >=20 > The chairs are now calling for consensus of the working group on this > point. Working group participants who were not present at the = interim, > please review the input documents if you not have yet done so, and > forward your comments to the list. All working group participants are > asked to make > their points on this topic by February 22nd, so that we have timely > input prior to the document deadline for Paris. >=20 > thanks, >=20 > Ted Hardie for the Chairs > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail=_E2E8419F-47C7-4B1C-8ABF-0198B108FABE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii This = is partially inevitable.  For WebRTC applications that interact = with SIP gateways, the WebRTC application can't signal anything that = 3264 won't allow, since the gateway's side won't be able to deal with = it.  The original architecture document http://t= ools.ietf.org/html/draft-ietf-rtcweb-overview-02 proposes a RTC = trapezoid and any well-behaved trapezoid needs to consider the SIP case = and therefore 3264.

There is another important case, = which is when the trapezoid degenerates into a triangle.  This is = the case where the web server controls both sides of the conversation = (e.g. connecting to an attendant at www.ftd.com without any intervening = PBX/switch/traditional contact center).  Since there is no PSTN GW = to contend with, it's not necessary to obey the gateway's rules. =  In this case, the server presumably knows what it's doing, so it's = probably a bug if it trips itself up.

There is = potentially a third case, which is where the trapezoid is maintained, = and the servers are communicating with some-protocol-not-SIP that = doesn't need to abide by 3264 (which excludes H.323), but are not smart = enough to coordinate media between themselves, but this doesn't seem = very important.  I could be wrong about that, but I don't see the = practical use = case.

Cary.

On Feb 21, = 2012, at 8:52 AM, Ejzak, Richard P (Richard) wrote:

Hi = All,
I would like to point out that if you rephrase the question to = ask "who prefers to base subsequent work on RFC 3264 semantics?", then = you would need to combine positions 2 and 4, and you would get a vote of = 28 (the position 3 votes) for a new semantic model (requiring = significant new work on SDP) against 21 (the sum of votes for positions = 2 and 4) for RFC 3264 semantics.

So while I do not object to = using JSEP as a basis for further work, it seems that the group is far = less certain about the on-the-wire semantics to be associated with it. =  My preference is to focus on RFC 3264 semantics (noting that the = low level of the API would still allow considerable flexibility to = support other signaling protocols).  My key concern is to have = clear rules (based on common semantics) for interworking media/transport = negotiation procedures between different on-the-wire protocols to avoid = potential interop problems.  

In particular, at this point = in the discussion, I do not see the value of allowing multiple open = OFFERs within a dialog (which have acknowledged problems), multiple = ANSWERs within a dialog, or PRANSWERs, none of which exist in RFC = 3264.

I propose that the group first decide whether to use JSEP = as a basis for further work and in subsequent step(s) decide whether and = how to go beyond RFC 3264 semantics.  I see this proposal as simply = a clarification of the meaning of position 3.

Richard = Ejzak

-----Original Message-----
From: rtcweb-bounces@ietf.org = [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ted Hardie
Sent: = Tuesday, February 07, 2012 2:25 PM
To: rtcweb@ietf.org
Subject: [rtcweb] = Consensus call on JSEP/ROAP

During the interim meeting, the = attendees discussed the JSEP and ROAP
proposals.  The chairs = also asked the working group to consider
whether they might be = successfully merged.  Because of audio difficulties,
there is no = recording available.  The jabber logs contain
a transcription of = the discussion by Bernard Aboba and can be found
here: http://www= .ietf.org/jabber/logs/rtcweb/2012-01-31.html.

At the end of = the discussion, the chairs asked the attendees to
indicate their = preferences by standing for one of four positions, which were
listed = prior to the question being called.  The positions = were:

1--Don't care whether ROAP or JSEP is the input document = for further
work in this area

2---Prefer ROAP be the input = document for further work

3--Prefer JSEP be the input document = for further work

4--Prefer to merge the docs, limiting JSEP to = RFC 3264 offer/answer semantics.

The results were: 1=3D9 in room, = none in jabber
=             &n= bsp;           &nbs= p;   2=3D11 in room, 2 in jabber
=             &n= bsp;           &nbs= p;   3=3D25 in room, 3 in jabber
=             &n= bsp;           &nbs= p;   4=3D8 in room, none in jabber.

Because JSEP = supports more than one model of negotiation, choosing 3
is a reversal =  from previous working group consensus to limit work to
the = offer/answer model.

The chairs are now calling for consensus of = the working group on this
point.  Working group participants who = were not present at the interim,
please review the input documents if = you not have yet done so, and
forward your comments to the list. =  All working group participants are
asked to make
their = points on this topic by February 22nd, so that we have timely
input = prior to the document deadline for Paris.

thanks,

Ted = Hardie for the = Chairs
_______________________________________________
rtcweb = mailing list
rtcweb@ietf.org
https://www.ietf.or= g/mailman/listinfo/rtcweb
_____________________________________________= __
rtcweb mailing = list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

= --Apple-Mail=_E2E8419F-47C7-4B1C-8ABF-0198B108FABE-- From pravindran@sonusnet.com Tue Feb 21 12:53: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 7EDEA11E809B for ; Tue, 21 Feb 2012 12:53:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[AWL=-0.252, BAYES_00=-2.599, J_CHICKENPOX_65=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 XFGfIk5UEkIc for ; Tue, 21 Feb 2012 12:53:41 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id DF8DA11E8099 for ; Tue, 21 Feb 2012 12:53:40 -0800 (PST) Received: from sonusmail05.sonusnet.com (sonusmail05.sonusnet.com [10.128.32.155]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q1LKsLtm005790; Tue, 21 Feb 2012 15:54:21 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Feb 2012 15:50:51 -0500 Received: from INBA-HUB02.sonusnet.com ([10.70.51.87]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Feb 2012 02:21:05 +0530 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, 22 Feb 2012 02:21:04 +0530 From: "Ravindran, Parthasarathi" To: "Ejzak, Richard P (Richard)" , "rtcweb@ietf.org" , "public-webrtc@w3.org" , Randell Jesup Thread-Topic: [rtcweb] JSEP-02: New offer and answer to previous offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case] Thread-Index: AQHM8AqE+28vByK84kKxG08H/gll95ZF3BIAgAAASYCAAASXgIAAGTuAgADuMECAAH0N0IAAZRbg Date: Tue, 21 Feb 2012 20:51:02 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E0412EB@inba-mail01.sonusnet.com> References: <7F2072F1E0DE894DA4B517B93C6A05852C3D31BA37@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C3D31BA3A@ESESSCMS0356.eemea.ericsson.se> <4F42C2C7.3060802@jesup.org> <387F9047F55E8C42850AD6B3A7A03C6C0E040FFE@inba-mail01.sonusnet.com> <6F428EFD2B8C2F49A2FB1317291A76C11355D49C4E@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> In-Reply-To: <6F428EFD2B8C2F49A2FB1317291A76C11355D49C4E@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: multipart/mixed; boundary="_003_387F9047F55E8C42850AD6B3A7A03C6C0E0412EBinbamail01sonus_" MIME-Version: 1.0 X-OriginalArrivalTime: 21 Feb 2012 20:51:05.0020 (UTC) FILETIME=[8749CFC0:01CCF0DA] Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case] 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, 21 Feb 2012 20:53:45 -0000 --_003_387F9047F55E8C42850AD6B3A7A03C6C0E0412EBinbamail01sonus_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, Till now, I'm writing the callflow with the assumption of browser as RTP En= dpoint. Two JSEP example call flow are attached: 1) Two 180 with SDP (answer) and second 180's dialog comes up with 2xx wit= h SDP 2) Two 180 with SDP (answer) and first 180's dialog comes up with 2xx= with SDP The above callflows are not the only way to solve the problem but it is one= of the way to solve this callflow. The intention of these callflows are to= indicate that multiple answers support in JSEP facilities for designing SI= P parallel forking kind of services. The exact intention is as per http://= www.ietf.org/mail-archive/web/rtcweb/current/msg03455.html and as follows: 1) allow a setRemoteDesc(SDP_ANSWER) to follow a setRemoteDesc(SDP_ANSWER) 2) document that in this case (multiple 2xx), the JS is responsible for sen= ding BYE to the previous answerer. Please let me know your comments on the callflow. Hi Richard,=20 Thanks for your clarification in the below mail. Please read inline for mor= e comments Thanks Partha >-----Original Message----- >From: Ejzak, Richard P (Richard) [mailto:richard.ejzak@alcatel- >lucent.com] >Sent: Tuesday, February 21, 2012 8:05 PM >To: Ravindran, Parthasarathi; rtcweb@ietf.org; public-webrtc@w3.org >Subject: RE: [rtcweb] JSEP-02: New offer and answer to previous offer >[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] > >Hi Partha, >Regarding my earlier email (this earlier email was not distributed on >the webrtc list), I do not dispute that forking must be supported by all >SIP endpoints. Let me rephrase my earlier questions in light of your >latest call flow. > >Looking at your call flow, I see that you treat the case of multiple >answers from the same endpoint as a serial forking case (or do I >misunderstand your intent?).=20 I agree that this callflow is allowed in JSEP and it is a violatio= n of RFC 3261 and not RFC 3264. I explained in detail why this callflow sha= ll be allowed in http://www.ietf.org/mail-archive/web/rtcweb/current/msg034= 78.html How do you determine that this is a >special type of serial forking and not a parallel forking case?=20 I won't determine it. I will just update based on the last active = answer. We have >at least three use cases for multiple ANSWER and it would be helpful to >see how they can be handled and distinguished in SIP signaling. > Please mentioned the three of them. I'll provide the callflow for = the same >Also, PRANSWER as currently defined seems to have no analog in SIP. Is >this also your understanding? We have the common understanding here. I'm requesting to remove PR= _ANSWER state as it complicates JS Offer/Answer FSM still more (See: http:/= /www.ietf.org/mail-archive/web/rtcweb/current/msg03489.html). > >I don't understand your statement that "It is possible to implement >parallel forking by keeping only one answer active in the offerer side >at the given time". It would appear that an implementation of parallel >forking would need to keep the last answer from each dialog active. >Please explain. > Hope the callflow clarifies >I look forward to your next call flow. > >Richard > >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of Ravindran, Parthasarathi >Sent: Tuesday, February 21, 2012 12:58 AM >To: Randell Jesup; rtcweb@ietf.org; public-webrtc@w3.org >Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous offer >[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] > >Randell, > >It is possible to implement parallel forking by keeping only one answer >active in the offerer side at the given time. I attached one of the >example "18x with SDP and 2xx with different SDP" for your reference >which will map to serial forking. Please let me know your concern about >ICE interaction concern here. > >I'll send multiple 18x with SDP and one 2xx with SDP response JSEP >example using UPDATE O/A mechanism ASAP for clarity on parallel forking >(assumption: multiple answer for single offer is supported in JSEP). > >Thanks >Partha > >>-----Original Message----- >>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >>Behalf Of Randell Jesup >>Sent: Tuesday, February 21, 2012 3:32 AM >>To: rtcweb@ietf.org; public-webrtc@w3.org >>Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous offer >>[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] >> >>On 2/20/2012 3:31 PM, Roman Shpount wrote: >>> Not to beat this horse to death, but why is it "suggested not to have >>> parallel forking"? WebRTC intorduces additional restrictions on RTP >>> stream (remote media sources and SSRCs are known in advance) that >>> make parallel forking implementation trivial. Only thing that is >>> missing is some way to clone the PeerConnection in the API. >> >>Right; parallel forking has uses. >> >>We've talked about this, but not for a while. One way to implement it >>would be to on each forked answer clone the state of the PeerConnection >>as it was with any previous answer removed. However, I'm concerned >>about how this will interact with the ICE, etc stuff. Someone want to >>throw out a suggestion? Cullen, Justin - how *should*/*could* forking >>work within JSEP? >> >> >>Aside on uses of forking: >>I can see some additional interesting uses for parallel forking, >>especially in non-phone-like usecases (games among others). The server >>(or another participant) could hold open an OFFER in order to forward >>it to any potential new partners. This might apply to a conference >>call as well if there's a peer-2-peer aspect (mesh, partial-mesh, etc) >to it. >> >>Think in a game or 2nd-life-type-sim, where you're automatically in a >>voice chat with anyone within hearing range, and those voice chats are >>done p2p by forking each player's original offer to the server, and >>forwarding it (forking it) to the new user, who would answer and they'd >>be in a call. >> >>If you wanted to get really fancy, you could even do some of the >>negotiation in the server and rephrase each offer as an answer to the >>other side, leading to a 1/2-RTT-to-the-server setup time (more-or- >less: >> >>player 1 server player 2 >>------------------------------------------------------------ >>| | | >>|--> Offer 1 ---------------->| | >>| |<---------- Offer 2 <----| >>| | | >>... >> Server decides they should talk >>| | | >>|<-- Answer(Offer 2) <--------|-----> Answer(Offer 1)-->| >>|<------------------------- media --------------------->| >> >>Even if this is initiated by a player, there are equivalent graphs that >>use 1/2 RTT (through the server to other player) to set up channels. >> >>I should note however that ICE overhead may well swamp this fancy setup >>and it may be over-reaching, but each 1/2 RTT removed is significant, >>so there may be uses. >> >>> _____________ >>> Roman Shpount >>> >>> >>> On Mon, Feb 20, 2012 at 3:14 PM, Christer Holmberg >>> >> > >>> wrote: >>> >>> >>> Hi, >>> >>> Just to clarify: the new offer is for the same "session" as the >>> previous offer, and is supposed to replace the previous offer. >>> >>> The browser can of course send a just-audio offer somewhere, and >a >>> just-video offer somewhere else, but would those even be >>associated >>> with the same PeerConnection? I thought we wanted only one >>> offer/answer, which is the reason it has been suggested e.g. not >>to >>> support paralell forking in the browser. >>> >>> Regards, >>> >>> Christer >>> ________________________________________ >>> From: I=F1aki Baz Castillo [ibc@aliax.net ] >>> Sent: Monday, February 20, 2012 10:13 PM >>> To: Christer Holmberg >>> Cc: Justin Uberti; rtcweb@ietf.org ; >>> public-webrtc@w3.org >>> Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous >>> offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case] >>> >>> 2012/2/20 Christer Holmberg >> >: >>> > Q1. When the JS app requests the new offer (o-2), I assume all >>> resources etc associated with o-1 will be released (unless they >>are >>> also needed for o-2, that is). >>> >>> Does it mean that the browser is just capable of having *one* >>> multimedia session at the same time? Well, in SIP world this >>typically >>> means putting on-hold the previous call so, indeed, resources >>would be >>> released. >>> >>> But, why couldn't the browser send a just-audio offer somewhere >>and a >>> just-video offer to other destination at the same time? >>> >>> -- >>> I=F1aki Baz Castillo >>> > >>> _______________________________________________ >>> 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 >> >> >>-- >>Randell Jesup >>randell-ietf@jesup.org >>_______________________________________________ >>rtcweb mailing list >>rtcweb@ietf.org >>https://www.ietf.org/mailman/listinfo/rtcweb --_003_387F9047F55E8C42850AD6B3A7A03C6C0E0412EBinbamail01sonus_ Content-Type: text/plain; name="Mutliple 18x with SDP and 2xx with SDP.txt" Content-Description: Mutliple 18x with SDP and 2xx with SDP.txt Content-Disposition: attachment; filename="Mutliple 18x with SDP and 2xx with SDP.txt"; size=2072; creation-date="Tue, 21 Feb 2012 19:48:39 GMT"; modification-date="Tue, 21 Feb 2012 20:46:50 GMT" Content-Transfer-Encoding: base64 SGFuZGxpbmcgTXVsdGlwbGUgMTh4IHdpdGggU0RQIGFuZCAyeHggd2l0aFNEUCwgdXNpbmcgU0lQ DQoNCiAgIFRoaXMgZXhhbXBsZSBkZW1vbnN0cmF0ZXMgaG93IE11bHRpcGxlIDE4eCB3aXRoIFNE UCBjb3VsZCBiZSBoYW5kbGVkOyBmb3INCiAgIHNpbXBsaWNpdHksIG9ubHkgdGhlIG9mZmVyZXIg c2lkZSBvZiB0aGUgY2FsbCBpcyBzaG93bi4NCg0KICAgLy8gQ2FsbCBpcyBpbml0aWF0ZWQgdG93 YXJkIEFuc3dlcmVyDQogICBPZmZlcmVySlMtPk9mZmVyZXJVQTogICBwYyA9IG5ldyBQZWVyQ29u bmVjdGlvbigpOw0KICAgT2ZmZXJlckpTLT5PZmZlcmVyVUE6ICAgcGMuYWRkU3RyZWFtKGxvY2Fs U3RyZWFtLCBudWxsKTsNCiAgIE9mZmVyZXJKUy0+T2ZmZXJlclVBOiAgIHBjLnN0YXJ0SWNlKCk7 DQogICBPZmZlcmVyVUEtPk9mZmVyZXJKUzogICBpY2VDYWxsYmFjayhjYW5kaWRhdGUsIGZhbHNl KTsNCiAgIE9mZmVyZXJKUy0+T2ZmZXJlclVBOiAgIG9mZmVyID0gcGMuY3JlYXRlT2ZmZXIobnVs bCk7DQogICBPZmZlcmVySlMtPk9mZmVyZXJVQTogICBwYy5zZXRMb2NhbERlc2NyaXB0aW9uKFNE UF9PRkZFUiwgb2ZmZXIpOw0KICAgT2ZmZXJlckpTOiAgICAgICAgICAgICAgSU5WSVRFID0gY3Jl YXRlSW52aXRlKG9mZmVyKTsNCiAgIE9mZmVyZXJKUy0+QW5zd2VyZXJKUzogIFNJUCBJTlZJVEUg dy8gU0RQDQoNCiAgIC8vIDE4MCBSaW5naW5nIGlzIHJlY2VpdmVkIGJ5IG9mZmVyZXIsIHcvU0RQ MSBmcm9tIGFuc3dlcmVyMQ0KICAgT2ZmZXJlckpTOiAgICAgICAgICAgICAgYW5zd2VyMSA9IHBh cnNlUmVzcG9uc2Uoc2lwKTsNCiAgIE9mZmVyZXJKUy0+T2ZmZXJlclVBOiAgIHBjLnNldFJlbW90 ZURlc2NyaXB0aW9uKFNEUF9BTlNXRVIsIGFuc3dlcjEpOw0KICAgT2ZmZXJlclVBLT5PZmZlcmVy SlM6ICAgb25hZGRzdHJlYW0ocmVtb3RlU3RyZWFtKTsNCg0KICAgLy8gSUNFIENvbXBsZXRlcyAo YXQgT2ZmZXJlcikNCiAgIE9mZmVyZXJVQS0+T2ZmZXJlckpTOiAgIG9ub3BlbigpOw0KICAgT2Zm ZXJlckpTLT5BbnN3ZXJlcjFKUzogIHsidHlwZSI6Ik9LIiB9DQogICBPZmZlcmVyVUEtPkFuc3dl cmVyMVVBOiAgTWVkaWENCg0KICAgLy8gMTgwIFJpbmdpbmcgaXMgcmVjZWl2ZWQgYnkgb2ZmZXJl ciwgdy9TRFAyIGZyb20gYW5zd2VyZXIyDQogICBPZmZlcmVySlM6ICAgICAgICAgICAgICBhbnN3 ZXIyID0gcGFyc2VSZXNwb25zZShzaXApOw0KICAgT2ZmZXJlckpTLT5PZmZlcmVyVUE6ICAgcGMu c2V0UmVtb3RlRGVzY3JpcHRpb24oU0RQX0FOU1dFUiwgYW5zd2VyMik7DQogICBPZmZlcmVyVUEt Pk9mZmVyZXJKUzogICBvbmFkZHN0cmVhbShyZW1vdGVTdHJlYW0pOw0KICAgT2ZmZXJlckpTOiAg ICAgICAgICAgICAgb2ZmZXJfYW5zd2VyMSA9IGNyZWF0ZUluYWN0aXZlRGlyZWN0aW9uU2RwKGFu c3dlcjEpOyAgICAgICAgDQogICBPZmZlcmVySlM6CQkgICBVUERBVEUgPSBjcmVhdGVVcGRhdGUo b2ZmZXJfYW5zd2VyMSk7IA0KICAgT2ZmZXJlckpTLT5BbnN3ZXJlcjFKUzogIFNJUCBVUERBVEUg dy9TRFANCiAgICAgICAgICAgICAgICAgICANCg0KICAgLy8gSUNFIENvbXBsZXRlcyAoYXQgT2Zm ZXJlciBmb3IgYW5zd2VyMg0KICAgT2ZmZXJlclVBLT5PZmZlcmVySlM6ICAgb25vcGVuKCk7DQog ICBPZmZlcmVySlMtPkFuc3dlcmVyMkpTOiAgeyJ0eXBlIjoiT0siIH0NCiAgIE9mZmVyZXJVQS0+ QW5zd2VyZXIxVUE6ICBNZWRpYQ0KDQogICAgIA0KICAgLy8gMjAwIE9LIGZvciBVUERBVEUgaXMg cmVjZWl2ZWQgYnkgb2ZmZXJlciwgdy9zZHAzIGZyb20gYW5zd2VyZXIxDQogICAvLyBObyBVUERB VEUgb24gT2ZmZXJlclVBIGFzIGl0IGlzIGhvbGQgcmVxdWVzdCB0b3dhcmRzIGFuc3dlcmVyMQ0K ICAgb2ZmZXJlckpTOiAgICAgICBhbnN3ZXIzID0gcGFyc2VSZXNwb25zZShzaXApICAgICAgICAg ICANCg0KICAgLy8gMjAwIE9LIGFycml2ZXMgYXQgT2ZmZXJlciwgdy9zZHAyIGZyb20gYW5zd2Vy ZXIyDQogICBPZmZlcmVySlMtPkFuc3dlcmVyMkpTOiAgQUNLDQogICBPZmZlcmVySlMtPkFuc3dl cmVyMUpTOiAgQllFDQoNCg0KDQo= --_003_387F9047F55E8C42850AD6B3A7A03C6C0E0412EBinbamail01sonus_ Content-Type: text/plain; name="Mutliple 18x with SDP and 2xx with different SDP.txt" Content-Description: Mutliple 18x with SDP and 2xx with different SDP.txt Content-Disposition: attachment; filename="Mutliple 18x with SDP and 2xx with different SDP.txt"; size=2626; creation-date="Tue, 21 Feb 2012 18:17:55 GMT"; modification-date="Tue, 21 Feb 2012 20:47:45 GMT" Content-Transfer-Encoding: base64 SGFuZGxpbmcgTXVsdGlwbGUgMTh4IHdpdGggU0RQIGFuZCAyeHggd2l0aCBkaWZmZXJlbnQgU0RQ LCB1c2luZyBTSVANCg0KICAgVGhpcyBleGFtcGxlIGRlbW9uc3RyYXRlcyBob3cgTXVsdGlwbGUg MTh4IHdpdGggU0RQIGNvdWxkIGJlIGhhbmRsZWQ7IGZvcg0KICAgc2ltcGxpY2l0eSwgb25seSB0 aGUgb2ZmZXJlciBzaWRlIG9mIHRoZSBjYWxsIGlzIHNob3duLg0KDQogICAvLyBDYWxsIGlzIGlu aXRpYXRlZCB0b3dhcmQgQW5zd2VyZXINCiAgIE9mZmVyZXJKUy0+T2ZmZXJlclVBOiAgIHBjID0g bmV3IFBlZXJDb25uZWN0aW9uKCk7DQogICBPZmZlcmVySlMtPk9mZmVyZXJVQTogICBwYy5hZGRT dHJlYW0obG9jYWxTdHJlYW0sIG51bGwpOw0KICAgT2ZmZXJlckpTLT5PZmZlcmVyVUE6ICAgcGMu c3RhcnRJY2UoKTsNCiAgIE9mZmVyZXJVQS0+T2ZmZXJlckpTOiAgIGljZUNhbGxiYWNrKGNhbmRp ZGF0ZSwgZmFsc2UpOw0KICAgT2ZmZXJlckpTLT5PZmZlcmVyVUE6ICAgb2ZmZXIgPSBwYy5jcmVh dGVPZmZlcihudWxsKTsNCiAgIE9mZmVyZXJKUy0+T2ZmZXJlclVBOiAgIHBjLnNldExvY2FsRGVz Y3JpcHRpb24oU0RQX09GRkVSLCBvZmZlcik7DQogICBPZmZlcmVySlM6ICAgICAgICAgICAgICBJ TlZJVEUgPSBjcmVhdGVJbnZpdGUob2ZmZXIpOw0KICAgT2ZmZXJlckpTLT5BbnN3ZXJlckpTOiAg U0lQIElOVklURSB3LyBTRFANCg0KICAgLy8gMTgwIFJpbmdpbmcgaXMgcmVjZWl2ZWQgYnkgb2Zm ZXJlciwgdy9TRFAxIGZyb20gYW5zd2VyZXIxDQogICBPZmZlcmVySlM6ICAgICAgICAgICAgICBh bnN3ZXIxID0gcGFyc2VSZXNwb25zZShzaXApOw0KICAgT2ZmZXJlckpTLT5PZmZlcmVyVUE6ICAg cGMuc2V0UmVtb3RlRGVzY3JpcHRpb24oU0RQX0FOU1dFUiwgYW5zd2VyMSk7DQogICBPZmZlcmVy VUEtPk9mZmVyZXJKUzogICBvbmFkZHN0cmVhbShyZW1vdGVTdHJlYW0pOw0KDQogICAvLyBJQ0Ug Q29tcGxldGVzIChhdCBPZmZlcmVyKQ0KICAgT2ZmZXJlclVBLT5PZmZlcmVySlM6ICAgb25vcGVu KCk7DQogICBPZmZlcmVySlMtPkFuc3dlcmVyMUpTOiAgeyJ0eXBlIjoiT0siIH0NCiAgIE9mZmVy ZXJVQS0+QW5zd2VyZXIxVUE6ICBNZWRpYQ0KDQogICAvLyAxODAgUmluZ2luZyBpcyByZWNlaXZl ZCBieSBvZmZlcmVyLCB3L1NEUDIgZnJvbSBhbnN3ZXJlcjINCiAgIE9mZmVyZXJKUzogICAgICAg ICAgICAgIGFuc3dlcjIgPSBwYXJzZVJlc3BvbnNlKHNpcCk7DQogICBPZmZlcmVySlMtPk9mZmVy ZXJVQTogICBwYy5zZXRSZW1vdGVEZXNjcmlwdGlvbihTRFBfQU5TV0VSLCBhbnN3ZXIyKTsNCiAg IE9mZmVyZXJVQS0+T2ZmZXJlckpTOiAgIG9uYWRkc3RyZWFtKHJlbW90ZVN0cmVhbSk7DQogICBP ZmZlcmVySlM6ICAgICAgICAgICAgICBvZmZlcl9hbnN3ZXIxID0gY3JlYXRlSW5hY3RpdmVEaXJl Y3Rpb25TZHAoYW5zd2VyMSk7ICAgICAgICANCiAgIE9mZmVyZXJKUzoJCSAgIFVQREFURSA9IGNy ZWF0ZVVwZGF0ZShvZmZlcl9hbnN3ZXIxKTsgDQogICBPZmZlcmVySlMtPkFuc3dlcmVyMUpTOiAg U0lQIFVQREFURSB3L1NEUA0KICAgICAgICAgICAgICAgICAgIA0KDQogICAvLyBJQ0UgQ29tcGxl dGVzIChhdCBPZmZlcmVyIGZvciBhbnN3ZXIyDQogICBPZmZlcmVyVUEtPk9mZmVyZXJKUzogICBv bm9wZW4oKTsNCiAgIE9mZmVyZXJKUy0+QW5zd2VyZXIySlM6ICB7InR5cGUiOiJPSyIgfQ0KICAg T2ZmZXJlclVBLT5BbnN3ZXJlcjFVQTogIE1lZGlhDQoNCiAgICAgDQogICAvLyAyMDAgT0sgZm9y IFVQREFURSBpcyByZWNlaXZlZCBieSBvZmZlcmVyLCB3L3NkcDMgZnJvbSBhbnN3ZXJlcjENCiAg IG9mZmVyZXJKUzogICAgICAgYW5zd2VyMyA9IHBhcnNlUmVzcG9uc2Uoc2lwKQ0KDQogICAvLyAy MDAgT0sgYXJyaXZlcyBhdCBPZmZlcmVyLCB3L3NkcDMgZnJvbSBhbnN3ZXJlcjENCiAgIE9mZmVy ZXJKUzogICAgICAgICAgICAgIGFuc3dlcjMgPSBwYXJzZVJlc3BvbnNlKHNpcCk7DQogICBPZmZl cmVySlMtPkFuc3dlcmVyMUpTOiAgQUNLDQogICBPZmZlcmVySlM6ICAgICAgICAgICAgICBvZmZl cl9hbnN3ZXIxID0gYW5zd2VyMTsNCiAgIE9mZmVyZXJKUzoJCSAgIFVQREFURSA9IGNyZWF0ZVVw ZGF0ZShvZmZlcl9hbnN3ZXIxKTsgDQogICBPZmZlcmVySlMtPkFuc3dlcmVyMUpTOiAgU0lQIFVQ REFURSB3L1NEUCANCg0KICAvLyAyMDAgT0sgZm9yIFVQREFURSBpcyByZWNlaXZlZCBieSBvZmZl cmVyLCB3L3NkcDMgZnJvbSBhbnN3ZXJlcjENCiAgIG9mZmVyZXJKUzogICAgICAgYW5zd2VyNCA9 IHBhcnNlUmVzcG9uc2Uoc2lwKQ0KICAgT2ZmZXJlckpTLT5PZmZlcmVyVUE6ICAgcGMuc2V0UmVt b3RlRGVzY3JpcHRpb24oU0RQX0FOU1dFUiwgYW5zd2VyNCk7DQogICBPZmZlcmVyVUEtPk9mZmVy ZXJKUzogICBvbmFkZHN0cmVhbShyZW1vdGVTdHJlYW0pOw0KICAgT2ZmZXJlckpTLT5BbnN3ZXJl cjJKUzogIEJZRQ0KDQogICAvLyBJQ0UgQ29tcGxldGVzIChhdCBPZmZlcmVyKQ0KICAgT2ZmZXJl clVBLT5PZmZlcmVySlM6ICAgb25vcGVuKCk7DQogICBPZmZlcmVySlMtPkFuc3dlcmVyMUpTOiAg eyJ0eXBlIjoiT0siIH0NCiAgIE9mZmVyZXJVQS0+QW5zd2VyZXIxVUE6ICBNZWRpYQ0KDQoNCg0K DQoNCg== --_003_387F9047F55E8C42850AD6B3A7A03C6C0E0412EBinbamail01sonus_-- From Jim.Barnett@genesyslab.com Tue Feb 21 13:12: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 86E2C11E808A for ; Tue, 21 Feb 2012 13:12:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.186 X-Spam-Level: X-Spam-Status: No, score=-2.186 tagged_above=-999 required=5 tests=[AWL=-0.187, BAYES_00=-2.599, J_CHICKENPOX_65=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 YlSrU+VHJ9CE for ; Tue, 21 Feb 2012 13:12:46 -0800 (PST) Received: from relay-out1.wc.genesyslab.com (relay-out1.wc.genesyslab.com [198.49.180.223]) by ietfa.amsl.com (Postfix) with ESMTP id 27A9011E8083 for ; Tue, 21 Feb 2012 13:12:45 -0800 (PST) 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 q1LLCjSJ017348; Tue, 21 Feb 2012 13:12:46 -0800 (PST) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Feb 2012 13:12:44 -0800 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, 21 Feb 2012 13:12:39 -0800 Message-ID: In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E0412EB@inba-mail01.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] JSEP-02: New offer and answer to previous offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case] Thread-Index: AQHM8AqE+28vByK84kKxG08H/gll95ZF3BIAgAAASYCAAASXgIAAGTuAgADuMECAAH0N0IAAZRbggAAO+MA= References: <7F2072F1E0DE894DA4B517B93C6A05852C3D31BA37@ESESSCMS0356.eemea.ericsson.se><7F2072F1E0DE894DA4B517B93C6A05852C3D31BA3A@ESESSCMS0356.eemea.ericsson.se><4F42C2C7.3060802@jesup.org><387F9047F55E8C42850AD6B3A7A03C6C0E040FFE@inba-mail01.sonusnet.com><6F428EFD2B8C2F49A2FB1317291A76C11355D49C4E@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <387F9047F55E8C42850AD6B3A7A03C6C0E0412EB@inba-mail01.sonusnet.com> From: "Jim Barnett" To: "Ravindran, Parthasarathi" , "EJZAK Richard" , , , "Randell Jesup" X-OriginalArrivalTime: 21 Feb 2012 21:12:44.0787 (UTC) FILETIME=[8E028430:01CCF0DD] Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case] 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, 21 Feb 2012 21:12:50 -0000 One detail on the examples. As I understand section 5.1.3 of the JSEP = draft, the second argument to iceCallback is a flag indicating whether = more ICE candidates are coming. So when iceCallback is called with = 'false' as the second argument, it means ICE is done. In line 10 of = your examples, I see such a callback, but then later in the example at = line 21 I see "ICE completes (at Offerer)". Has ICE somehow been = restarted in the interim, or am I misunderstanding the example (or = section 5.1.3)? - Jim -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf = Of Ravindran, Parthasarathi Sent: Tuesday, February 21, 2012 3:51 PM To: EJZAK Richard; rtcweb@ietf.org; public-webrtc@w3.org; Randell Jesup Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous offer = [was: JSEP-02: SDP_PRANSWER and FEDEX use-case] Hi all, Till now, I'm writing the callflow with the assumption of browser as RTP = Endpoint. Two JSEP example call flow are attached: 1) Two 180 with SDP (answer) and second 180's dialog comes up with 2xx = with SDP 2) Two 180 with SDP (answer) and first 180's dialog comes up with = 2xx with SDP The above callflows are not the only way to solve the problem but it is = one of the way to solve this callflow. The intention of these callflows = are to indicate that multiple answers support in JSEP facilities for = designing SIP parallel forking kind of services. The exact intention is = as per http://www.ietf.org/mail-archive/web/rtcweb/current/msg03455.html = and as follows: 1) allow a setRemoteDesc(SDP_ANSWER) to follow a = setRemoteDesc(SDP_ANSWER) 2) document that in this case (multiple 2xx), the JS is responsible for = sending BYE to the previous answerer. Please let me know your comments on the callflow. Hi Richard,=20 Thanks for your clarification in the below mail. Please read inline for = more comments Thanks Partha >-----Original Message----- >From: Ejzak, Richard P (Richard) [mailto:richard.ejzak@alcatel-=20 >lucent.com] >Sent: Tuesday, February 21, 2012 8:05 PM >To: Ravindran, Parthasarathi; rtcweb@ietf.org; public-webrtc@w3.org >Subject: RE: [rtcweb] JSEP-02: New offer and answer to previous offer >[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] > >Hi Partha, >Regarding my earlier email (this earlier email was not distributed on=20 >the webrtc list), I do not dispute that forking must be supported by=20 >all SIP endpoints. Let me rephrase my earlier questions in light of=20 >your latest call flow. > >Looking at your call flow, I see that you treat the case of multiple=20 >answers from the same endpoint as a serial forking case (or do I=20 >misunderstand your intent?). I agree that this callflow is allowed in JSEP and it is a = violation of RFC 3261 and not RFC 3264. I explained in detail why this = callflow shall be allowed in = http://www.ietf.org/mail-archive/web/rtcweb/current/msg03478.html = How do you determine that this is a >special type of serial forking and not a parallel forking case?=20 I won't determine it. I will just update based on the last = active answer. We have >at least three use cases for multiple ANSWER and it would be helpful to = >see how they can be handled and distinguished in SIP signaling. > Please mentioned the three of them. I'll provide the callflow = for the same >Also, PRANSWER as currently defined seems to have no analog in SIP. Is = >this also your understanding? We have the common understanding here. I'm requesting to remove = PR_ANSWER state as it complicates JS Offer/Answer FSM still more (See: = http://www.ietf.org/mail-archive/web/rtcweb/current/msg03489.html). = > >I don't understand your statement that "It is possible to implement=20 >parallel forking by keeping only one answer active in the offerer side=20 >at the given time". It would appear that an implementation of parallel = >forking would need to keep the last answer from each dialog active. >Please explain. > Hope the callflow clarifies >I look forward to your next call flow. > >Richard > >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On=20 >Behalf Of Ravindran, Parthasarathi >Sent: Tuesday, February 21, 2012 12:58 AM >To: Randell Jesup; rtcweb@ietf.org; public-webrtc@w3.org >Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous offer >[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] > >Randell, > >It is possible to implement parallel forking by keeping only one answer = >active in the offerer side at the given time. I attached one of the=20 >example "18x with SDP and 2xx with different SDP" for your reference=20 >which will map to serial forking. Please let me know your concern about = >ICE interaction concern here. > >I'll send multiple 18x with SDP and one 2xx with SDP response JSEP=20 >example using UPDATE O/A mechanism ASAP for clarity on parallel forking >(assumption: multiple answer for single offer is supported in JSEP). > >Thanks >Partha > >>-----Original Message----- >>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On=20 >>Behalf Of Randell Jesup >>Sent: Tuesday, February 21, 2012 3:32 AM >>To: rtcweb@ietf.org; public-webrtc@w3.org >>Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous offer >>[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] >> >>On 2/20/2012 3:31 PM, Roman Shpount wrote: >>> Not to beat this horse to death, but why is it "suggested not to=20 >>> have parallel forking"? WebRTC intorduces additional restrictions on = >>> RTP stream (remote media sources and SSRCs are known in advance)=20 >>> that make parallel forking implementation trivial. Only thing that=20 >>> is missing is some way to clone the PeerConnection in the API. >> >>Right; parallel forking has uses. >> >>We've talked about this, but not for a while. One way to implement it = >>would be to on each forked answer clone the state of the=20 >>PeerConnection as it was with any previous answer removed. However,=20 >>I'm concerned about how this will interact with the ICE, etc stuff. =20 >>Someone want to throw out a suggestion? Cullen, Justin - how=20 >>*should*/*could* forking work within JSEP? >> >> >>Aside on uses of forking: >>I can see some additional interesting uses for parallel forking,=20 >>especially in non-phone-like usecases (games among others). The=20 >>server (or another participant) could hold open an OFFER in order to=20 >>forward it to any potential new partners. This might apply to a=20 >>conference call as well if there's a peer-2-peer aspect (mesh,=20 >>partial-mesh, etc) >to it. >> >>Think in a game or 2nd-life-type-sim, where you're automatically in a=20 >>voice chat with anyone within hearing range, and those voice chats are = >>done p2p by forking each player's original offer to the server, and=20 >>forwarding it (forking it) to the new user, who would answer and=20 >>they'd be in a call. >> >>If you wanted to get really fancy, you could even do some of the=20 >>negotiation in the server and rephrase each offer as an answer to the=20 >>other side, leading to a 1/2-RTT-to-the-server setup time (more-or- >less: >> >>player 1 server player 2 >>------------------------------------------------------------ >>| | | >>|--> Offer 1 ---------------->| | >>| |<---------- Offer 2 <----| >>| | | >>... >> Server decides they should talk >>| | | >>|<-- Answer(Offer 2) <--------|-----> Answer(Offer 1)-->| >>|<------------------------- media --------------------->| >> >>Even if this is initiated by a player, there are equivalent graphs=20 >>that use 1/2 RTT (through the server to other player) to set up = channels. >> >>I should note however that ICE overhead may well swamp this fancy=20 >>setup and it may be over-reaching, but each 1/2 RTT removed is=20 >>significant, so there may be uses. >> >>> _____________ >>> Roman Shpount >>> >>> >>> On Mon, Feb 20, 2012 at 3:14 PM, Christer Holmberg=20 >>> >> > >>> wrote: >>> >>> >>> Hi, >>> >>> Just to clarify: the new offer is for the same "session" as the >>> previous offer, and is supposed to replace the previous offer. >>> >>> The browser can of course send a just-audio offer somewhere, and >a >>> just-video offer somewhere else, but would those even be >>associated >>> with the same PeerConnection? I thought we wanted only one >>> offer/answer, which is the reason it has been suggested e.g. not >>to >>> support paralell forking in the browser. >>> >>> Regards, >>> >>> Christer >>> ________________________________________ >>> From: I=F1aki Baz Castillo [ibc@aliax.net = ] >>> Sent: Monday, February 20, 2012 10:13 PM >>> To: Christer Holmberg >>> Cc: Justin Uberti; rtcweb@ietf.org ; >>> public-webrtc@w3.org >>> Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous >>> offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case] >>> >>> 2012/2/20 Christer Holmberg >> >: >>> > Q1. When the JS app requests the new offer (o-2), I assume = all >>> resources etc associated with o-1 will be released (unless they >>are >>> also needed for o-2, that is). >>> >>> Does it mean that the browser is just capable of having *one* >>> multimedia session at the same time? Well, in SIP world this >>typically >>> means putting on-hold the previous call so, indeed, resources >>would be >>> released. >>> >>> But, why couldn't the browser send a just-audio offer somewhere >>and a >>> just-video offer to other destination at the same time? >>> >>> -- >>> I=F1aki Baz Castillo >>> > >>> _______________________________________________ >>> 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 >> >> >>-- >>Randell Jesup >>randell-ietf@jesup.org >>_______________________________________________ >>rtcweb mailing list >>rtcweb@ietf.org >>https://www.ietf.org/mailman/listinfo/rtcweb From roman@telurix.com Tue Feb 21 14:32:19 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 63C1611E807F for ; Tue, 21 Feb 2012 14:32:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.358 X-Spam-Level: X-Spam-Status: No, score=-0.358 tagged_above=-999 required=5 tests=[AWL=-2.382, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_SUMOF=5, 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 R60UmMlRUqMD for ; Tue, 21 Feb 2012 14:32:18 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4176611E80BE for ; Tue, 21 Feb 2012 14:32:18 -0800 (PST) Received: by dakl33 with SMTP id l33so7697085dak.31 for ; Tue, 21 Feb 2012 14:32:17 -0800 (PST) Received-SPF: pass (google.com: domain of roman@telurix.com designates 10.68.220.162 as permitted sender) client-ip=10.68.220.162; Authentication-Results: mr.google.com; spf=pass (google.com: domain of roman@telurix.com designates 10.68.220.162 as permitted sender) smtp.mail=roman@telurix.com Received: from mr.google.com ([10.68.220.162]) by 10.68.220.162 with SMTP id px2mr21026424pbc.47.1329863537945 (num_hops = 1); Tue, 21 Feb 2012 14:32:17 -0800 (PST) Received: by 10.68.220.162 with SMTP id px2mr17120308pbc.47.1329863537857; Tue, 21 Feb 2012 14:32:17 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id p7sm11657485pbs.24.2012.02.21.14.32.15 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Feb 2012 14:32:16 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so8192653pbc.31 for ; Tue, 21 Feb 2012 14:32:15 -0800 (PST) Received-SPF: pass (google.com: domain of roman@telurix.com designates 10.68.74.197 as permitted sender) client-ip=10.68.74.197; Received: from mr.google.com ([10.68.74.197]) by 10.68.74.197 with SMTP id w5mr80104224pbv.129.1329863535318 (num_hops = 1); Tue, 21 Feb 2012 14:32:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.74.197 with SMTP id w5mr65949834pbv.129.1329863535299; Tue, 21 Feb 2012 14:32:15 -0800 (PST) Received: by 10.68.130.132 with HTTP; Tue, 21 Feb 2012 14:32:15 -0800 (PST) In-Reply-To: <005BC7E2-88EE-4D8F-8AEA-4614D39A6DC6@employees.org> References: <6F428EFD2B8C2F49A2FB1317291A76C11355D49DF5@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <005BC7E2-88EE-4D8F-8AEA-4614D39A6DC6@employees.org> Date: Tue, 21 Feb 2012 17:32:15 -0500 Message-ID: From: Roman Shpount To: Cary W FitzGerald Content-Type: multipart/alternative; boundary=f46d040fa1e89f0d6804b980fb31 X-Gm-Message-State: ALoCoQl9LZjA7XA2kIAv7XgNihUXgAwMbmHnYT3iBrZ4AAQIHGtisJmPskMiUuXcvplAnjW7ofFp Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consensus call on JSEP/ROAP 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, 21 Feb 2012 22:32:19 -0000 --f46d040fa1e89f0d6804b980fb31 Content-Type: text/plain; charset=ISO-8859-1 Another issue is that real-life SIP deployments are often not RFC 3264 complaint. In particular it is not unusual to receive different SDP in provisional and final INVITE response. This does not fit offer/answer model since it implies multiple answers to one offer with subsequent answers overwriting previous ones. So, offer/answer compliance is insufficient even for the SIP interop. _____________ Roman Shpount On Tue, Feb 21, 2012 at 3:13 PM, Cary W FitzGerald wrote: > This is partially inevitable. For WebRTC applications that interact with > SIP gateways, the WebRTC application can't signal anything that 3264 won't > allow, since the gateway's side won't be able to deal with it. The > original architecture document > http://tools.ietf.org/html/draft-ietf-rtcweb-overview-02 proposes a RTC > trapezoid and any well-behaved trapezoid needs to consider the SIP case and > therefore 3264. > > There is another important case, which is when the trapezoid degenerates > into a triangle. This is the case where the web server controls both sides > of the conversation (e.g. connecting to an attendant at www.ftd.comwithout any intervening PBX/switch/traditional contact center). Since > there is no PSTN GW to contend with, it's not necessary to obey the > gateway's rules. In this case, the server presumably knows what it's > doing, so it's probably a bug if it trips itself up. > > There is potentially a third case, which is where the trapezoid is > maintained, and the servers are communicating with some-protocol-not-SIP > that doesn't need to abide by 3264 (which excludes H.323), but are not > smart enough to coordinate media between themselves, but this doesn't seem > very important. I could be wrong about that, but I don't see the practical > use case. > > Cary. > > On Feb 21, 2012, at 8:52 AM, Ejzak, Richard P (Richard) wrote: > > Hi All, > I would like to point out that if you rephrase the question to ask "who > prefers to base subsequent work on RFC 3264 semantics?", then you would > need to combine positions 2 and 4, and you would get a vote of 28 (the > position 3 votes) for a new semantic model (requiring significant new work > on SDP) against 21 (the sum of votes for positions 2 and 4) for RFC 3264 > semantics. > > So while I do not object to using JSEP as a basis for further work, it > seems that the group is far less certain about the on-the-wire semantics to > be associated with it. My preference is to focus on RFC 3264 semantics > (noting that the low level of the API would still allow considerable > flexibility to support other signaling protocols). My key concern is to > have clear rules (based on common semantics) for interworking > media/transport negotiation procedures between different on-the-wire > protocols to avoid potential interop problems. > > In particular, at this point in the discussion, I do not see the value of > allowing multiple open OFFERs within a dialog (which have acknowledged > problems), multiple ANSWERs within a dialog, or PRANSWERs, none of which > exist in RFC 3264. > > I propose that the group first decide whether to use JSEP as a basis for > further work and in subsequent step(s) decide whether and how to go beyond > RFC 3264 semantics. I see this proposal as simply a clarification of the > meaning of position 3. > > Richard Ejzak > > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf > Of Ted Hardie > Sent: Tuesday, February 07, 2012 2:25 PM > To: rtcweb@ietf.org > Subject: [rtcweb] Consensus call on JSEP/ROAP > > During the interim meeting, the attendees discussed the JSEP and ROAP > proposals. The chairs also asked the working group to consider > whether they might be successfully merged. Because of audio difficulties, > there is no recording available. The jabber logs contain > a transcription of the discussion by Bernard Aboba and can be found > here: http://www.ietf.org/jabber/logs/rtcweb/2012-01-31.html. > > At the end of the discussion, the chairs asked the attendees to > indicate their preferences by standing for one of four positions, which > were > listed prior to the question being called. The positions were: > > 1--Don't care whether ROAP or JSEP is the input document for further > work in this area > > 2---Prefer ROAP be the input document for further work > > 3--Prefer JSEP be the input document for further work > > 4--Prefer to merge the docs, limiting JSEP to RFC 3264 offer/answer > semantics. > > The results were: 1=9 in room, none in jabber > 2=11 in room, 2 in jabber > 3=25 in room, 3 in jabber > 4=8 in room, none in jabber. > > Because JSEP supports more than one model of negotiation, choosing 3 > is a reversal from previous working group consensus to limit work to > the offer/answer model. > > The chairs are now calling for consensus of the working group on this > point. Working group participants who were not present at the interim, > please review the input documents if you not have yet done so, and > forward your comments to the list. All working group participants are > asked to make > their points on this topic by February 22nd, so that we have timely > input prior to the document deadline for Paris. > > thanks, > > Ted Hardie for the Chairs > _______________________________________________ > 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 > > --f46d040fa1e89f0d6804b980fb31 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Another issue is that real-life SIP deployments are often not RFC 3264 comp= laint. In particular it is not unusual to receive different SDP in provisio= nal and final INVITE response. This does not fit offer/answer model since i= t implies multiple answers to one offer with subsequent answers overwriting= previous ones. So, offer/answer compliance is insufficient even for the SI= P interop.
_____________
Roman Shpount


On Tue, Feb 21, 2012 at 3:13 PM, Cary W = FitzGerald <= caryfitz@employees.org> wrote:
This is partially inevitable. =A0For We= bRTC applications that interact with SIP gateways, the WebRTC application c= an't signal anything that 3264 won't allow, since the gateway's= side won't be able to deal with it. =A0The original architecture docum= ent=A0http://tools.ietf.org/html/draft-ietf-rtcweb-overview-02<= /a>=A0proposes a RTC trapezoid and any well-behaved trapezoid needs to cons= ider the SIP case and therefore 3264.

There is another important case, which is when the trapezoid= degenerates into a triangle. =A0This is the case where the web server cont= rols both sides of the conversation (e.g. connecting to an attendant at www.ftd.com without any i= ntervening PBX/switch/traditional contact center). =A0Since there is no PST= N GW to contend with, it's not necessary to obey the gateway's rule= s. =A0In this case, the server presumably knows what it's doing, so it&= #39;s probably a bug if it trips itself up.

There is potentially a third case, which is where the t= rapezoid is maintained, and the servers are communicating with some-protoco= l-not-SIP that doesn't need to abide by 3264 (which excludes H.323), bu= t are not smart enough to coordinate media between themselves, but this doe= sn't seem very important. =A0I could be wrong about that, but I don'= ;t see the practical use case.

Cary.

On Feb 21, 2012, at 8:52 = AM, Ejzak, Richard P (Richard) wrote:

Hi All,
I would like to point out that if you rephrase the question t= o ask "who prefers to base subsequent work on RFC 3264 semantics?"= ;, then you would need to combine positions 2 and 4, and you would get a vo= te of 28 (the position 3 votes) for a new semantic model (requiring signifi= cant new work on SDP) against 21 (the sum of votes for positions 2 and 4) f= or RFC 3264 semantics.

So while I do not object to using JSEP as a basis for further work, it = seems that the group is far less certain about the on-the-wire semantics to= be associated with it. =A0My preference is to focus on RFC 3264 semantics = (noting that the low level of the API would still allow considerable flexib= ility to support other signaling protocols). =A0My key concern is to have c= lear rules (based on common semantics) for interworking media/transport neg= otiation procedures between different on-the-wire protocols to avoid potent= ial interop problems. =A0

In particular, at this point in the discussion, I do not see the value = of allowing multiple open OFFERs within a dialog (which have acknowledged p= roblems), multiple ANSWERs within a dialog, or PRANSWERs, none of which exi= st in RFC 3264.

I propose that the group first decide whether to use JSEP as a basis fo= r further work and in subsequent step(s) decide whether and how to go beyon= d RFC 3264 semantics. =A0I see this proposal as simply a clarification of t= he meaning of position 3.

Richard Ejzak

-----Original Message-----
From: rtcweb-bounces@ietf.org = [mailto:rtcweb= -bounces@ietf.org] On Behalf Of Ted Hardie
Sent: Tuesday, February 07, 2012 2:25 PM
To: rtcweb@ietf.org
Subject: [rtcweb] Consensu= s call on JSEP/ROAP

During the interim meeting, the attendees discus= sed the JSEP and ROAP
proposals. =A0The chairs also asked the working group to consider
whethe= r they might be successfully merged. =A0Because of audio difficulties,
t= here is no recording available. =A0The jabber logs contain
a transcripti= on of the discussion by Bernard Aboba and can be found
here: http://www.ietf.org/jabber/logs/rtcweb/2012-01-31.html.=

At the end of the discussion, the chairs asked the attendees to
indicate their preferences by standing for one of four positions, which wer= e
listed prior to the question being called. =A0The positions were:
<= br>1--Don't care whether ROAP or JSEP is the input document for further=
work in this area

2---Prefer ROAP be the input document for further = work

3--Prefer JSEP be the input document for further work

4-= -Prefer to merge the docs, limiting JSEP to RFC 3264 offer/answer semantics= .

The results were: 1=3D9 in room, none in jabber
=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A02=3D11 in= room, 2 in jabber
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A03=3D25 in room, 3 in jabber
=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= 4=3D8 in room, none in jabber.

Because JSEP supports more than one model of negotiation, choosing 3is a reversal =A0from previous working group consensus to limit work tothe offer/answer model.

The chairs are now calling for consensus of= the working group on this
point. =A0Working group participants who were not present at the interim,please review the input documents if you not have yet done so, and
for= ward your comments to the list. =A0All working group participants are
as= ked to make
their points on this topic by February 22nd, so that we have timely
inpu= t prior to the document deadline for Paris.

thanks,

Ted Hardi= e for the Chairs
_______________________________________________
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


--f46d040fa1e89f0d6804b980fb31-- From richard.ejzak@alcatel-lucent.com Tue Feb 21 14:44: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 52ACB11E80D0 for ; Tue, 21 Feb 2012 14:44:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.032 X-Spam-Level: X-Spam-Status: No, score=-8.032 tagged_above=-999 required=5 tests=[AWL=1.967, BAYES_00=-2.599, J_CHICKENPOX_65=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 WYsKCdt1AEkd for ; Tue, 21 Feb 2012 14:44:55 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB3F21F87D6 for ; Tue, 21 Feb 2012 14:44:55 -0800 (PST) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q1LMis9K006897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 Feb 2012 16:44:54 -0600 (CST) 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 q1LMirgk024697 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 21 Feb 2012 16:44:54 -0600 Received: from USNAVSXCHMBSA1.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Tue, 21 Feb 2012 16:44:53 -0600 From: "Ejzak, Richard P (Richard)" To: "Ravindran, Parthasarathi" , "rtcweb@ietf.org" , "public-webrtc@w3.org" Date: Tue, 21 Feb 2012 16:44:52 -0600 Thread-Topic: [rtcweb] JSEP-02: New offer and answer to previous offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case] Thread-Index: AQHM8AqE+28vByK84kKxG08H/gll95ZF3BIAgAAASYCAAASXgIAAGTuAgADuMECAAH0N0IAAZRbggAAhZzA= Message-ID: <6F428EFD2B8C2F49A2FB1317291A76C11355D4A115@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> References: <7F2072F1E0DE894DA4B517B93C6A05852C3D31BA37@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C3D31BA3A@ESESSCMS0356.eemea.ericsson.se> <4F42C2C7.3060802@jesup.org> <387F9047F55E8C42850AD6B3A7A03C6C0E040FFE@inba-mail01.sonusnet.com> <6F428EFD2B8C2F49A2FB1317291A76C11355D49C4E@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <387F9047F55E8C42850AD6B3A7A03C6C0E0412EB@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E0412EB@inba-mail01.sonusnet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case] 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, 21 Feb 2012 22:44:56 -0000 Hi Partha, Thanks for the call flows and explanations. For all of your flows, it would really help if any deviation from RFC 3261 = or RFC 3264 is clearly noted in your flows. Further, it would help to be c= lear when you assume reliable or unreliable provisionals, since that makes = a big difference. You appear to usually assume reliable provisionals, but = I want to be sure. It would also help to identify the purpose of some key operations in each f= low when not strictly for protocol conformance. For example, setting some = flows to "inactive" is used to avoid having multiple media flows when paral= lel forking, but this is an application choice rather than a protocol neces= sity. You state that your earlier flow violates RFC 3261, and in an earlier posti= ng you insist that it should be supported because some implementations beha= ve that way. I have a real problem with this. Standards are meant to help= in avoiding exactly this kind of situation and I don't think that non-stan= dard behavior should be condoned by rtcweb. If there is good reason to sup= port this kind of flow then it should be brought to the appropriate working= group for consideration (not rtcweb). An endpoint could achieve similar b= ehavior by mimicking standard serial forking procedures (which is what I th= ought you intended but you forgot to include the interim final responses or= byes). Why not just use a sequence of UPDATEs and avoid these hassles? The three use cases I had in mind were: 1) mimicking standard serial forking from a single endpoint to realize the = equivalent of multiple ANSWERs to a single OFFER (although separate OFFER/A= NSWER transactions using UPDATE would be cleaner) 2) standard serial forking (with optional UPDATEs) 3) standard parallel forking (with optional UPDATEs) Do we really need anything other than 2) and 3)? Richard -----Original Message----- From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com]=20 Sent: Tuesday, February 21, 2012 2:51 PM To: Ejzak, Richard P (Richard); rtcweb@ietf.org; public-webrtc@w3.org; Rand= ell Jesup Subject: RE: [rtcweb] JSEP-02: New offer and answer to previous offer [was:= JSEP-02: SDP_PRANSWER and FEDEX use-case] Hi all, Till now, I'm writing the callflow with the assumption of browser as RTP En= dpoint. Two JSEP example call flow are attached: 1) Two 180 with SDP (answer) and second 180's dialog comes up with 2xx wit= h SDP 2) Two 180 with SDP (answer) and first 180's dialog comes up with 2xx= with SDP The above callflows are not the only way to solve the problem but it is one= of the way to solve this callflow. The intention of these callflows are to= indicate that multiple answers support in JSEP facilities for designing SI= P parallel forking kind of services. The exact intention is as per http://= www.ietf.org/mail-archive/web/rtcweb/current/msg03455.html and as follows: 1) allow a setRemoteDesc(SDP_ANSWER) to follow a setRemoteDesc(SDP_ANSWER) 2) document that in this case (multiple 2xx), the JS is responsible for sen= ding BYE to the previous answerer. Please let me know your comments on the callflow. Hi Richard,=20 Thanks for your clarification in the below mail. Please read inline for mor= e comments Thanks Partha >-----Original Message----- >From: Ejzak, Richard P (Richard) [mailto:richard.ejzak@alcatel- >lucent.com] >Sent: Tuesday, February 21, 2012 8:05 PM >To: Ravindran, Parthasarathi; rtcweb@ietf.org; public-webrtc@w3.org >Subject: RE: [rtcweb] JSEP-02: New offer and answer to previous offer >[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] > >Hi Partha, >Regarding my earlier email (this earlier email was not distributed on >the webrtc list), I do not dispute that forking must be supported by all >SIP endpoints. Let me rephrase my earlier questions in light of your >latest call flow. > >Looking at your call flow, I see that you treat the case of multiple >answers from the same endpoint as a serial forking case (or do I >misunderstand your intent?).=20 I agree that this callflow is allowed in JSEP and it is a violatio= n of RFC 3261 and not RFC 3264. I explained in detail why this callflow sha= ll be allowed in http://www.ietf.org/mail-archive/web/rtcweb/current/msg034= 78.html How do you determine that this is a >special type of serial forking and not a parallel forking case?=20 I won't determine it. I will just update based on the last active = answer. We have >at least three use cases for multiple ANSWER and it would be helpful to >see how they can be handled and distinguished in SIP signaling. > Please mentioned the three of them. I'll provide the callflow for = the same >Also, PRANSWER as currently defined seems to have no analog in SIP. Is >this also your understanding? We have the common understanding here. I'm requesting to remove PR= _ANSWER state as it complicates JS Offer/Answer FSM still more (See: http:/= /www.ietf.org/mail-archive/web/rtcweb/current/msg03489.html). > >I don't understand your statement that "It is possible to implement >parallel forking by keeping only one answer active in the offerer side >at the given time". It would appear that an implementation of parallel >forking would need to keep the last answer from each dialog active. >Please explain. > Hope the callflow clarifies >I look forward to your next call flow. > >Richard > >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of Ravindran, Parthasarathi >Sent: Tuesday, February 21, 2012 12:58 AM >To: Randell Jesup; rtcweb@ietf.org; public-webrtc@w3.org >Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous offer >[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] > >Randell, > >It is possible to implement parallel forking by keeping only one answer >active in the offerer side at the given time. I attached one of the >example "18x with SDP and 2xx with different SDP" for your reference >which will map to serial forking. Please let me know your concern about >ICE interaction concern here. > >I'll send multiple 18x with SDP and one 2xx with SDP response JSEP >example using UPDATE O/A mechanism ASAP for clarity on parallel forking >(assumption: multiple answer for single offer is supported in JSEP). > >Thanks >Partha > >>-----Original Message----- >>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >>Behalf Of Randell Jesup >>Sent: Tuesday, February 21, 2012 3:32 AM >>To: rtcweb@ietf.org; public-webrtc@w3.org >>Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous offer >>[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] >> >>On 2/20/2012 3:31 PM, Roman Shpount wrote: >>> Not to beat this horse to death, but why is it "suggested not to have >>> parallel forking"? WebRTC intorduces additional restrictions on RTP >>> stream (remote media sources and SSRCs are known in advance) that >>> make parallel forking implementation trivial. Only thing that is >>> missing is some way to clone the PeerConnection in the API. >> >>Right; parallel forking has uses. >> >>We've talked about this, but not for a while. One way to implement it >>would be to on each forked answer clone the state of the PeerConnection >>as it was with any previous answer removed. However, I'm concerned >>about how this will interact with the ICE, etc stuff. Someone want to >>throw out a suggestion? Cullen, Justin - how *should*/*could* forking >>work within JSEP? >> >> >>Aside on uses of forking: >>I can see some additional interesting uses for parallel forking, >>especially in non-phone-like usecases (games among others). The server >>(or another participant) could hold open an OFFER in order to forward >>it to any potential new partners. This might apply to a conference >>call as well if there's a peer-2-peer aspect (mesh, partial-mesh, etc) >to it. >> >>Think in a game or 2nd-life-type-sim, where you're automatically in a >>voice chat with anyone within hearing range, and those voice chats are >>done p2p by forking each player's original offer to the server, and >>forwarding it (forking it) to the new user, who would answer and they'd >>be in a call. >> >>If you wanted to get really fancy, you could even do some of the >>negotiation in the server and rephrase each offer as an answer to the >>other side, leading to a 1/2-RTT-to-the-server setup time (more-or- >less: >> >>player 1 server player 2 >>------------------------------------------------------------ >>| | | >>|--> Offer 1 ---------------->| | >>| |<---------- Offer 2 <----| >>| | | >>... >> Server decides they should talk >>| | | >>|<-- Answer(Offer 2) <--------|-----> Answer(Offer 1)-->| >>|<------------------------- media --------------------->| >> >>Even if this is initiated by a player, there are equivalent graphs that >>use 1/2 RTT (through the server to other player) to set up channels. >> >>I should note however that ICE overhead may well swamp this fancy setup >>and it may be over-reaching, but each 1/2 RTT removed is significant, >>so there may be uses. >> >>> _____________ >>> Roman Shpount >>> >>> >>> On Mon, Feb 20, 2012 at 3:14 PM, Christer Holmberg >>> >> > >>> wrote: >>> >>> >>> Hi, >>> >>> Just to clarify: the new offer is for the same "session" as the >>> previous offer, and is supposed to replace the previous offer. >>> >>> The browser can of course send a just-audio offer somewhere, and >a >>> just-video offer somewhere else, but would those even be >>associated >>> with the same PeerConnection? I thought we wanted only one >>> offer/answer, which is the reason it has been suggested e.g. not >>to >>> support paralell forking in the browser. >>> >>> Regards, >>> >>> Christer >>> ________________________________________ >>> From: I=F1aki Baz Castillo [ibc@aliax.net ] >>> Sent: Monday, February 20, 2012 10:13 PM >>> To: Christer Holmberg >>> Cc: Justin Uberti; rtcweb@ietf.org ; >>> public-webrtc@w3.org >>> Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous >>> offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case] >>> >>> 2012/2/20 Christer Holmberg >> >: >>> > Q1. When the JS app requests the new offer (o-2), I assume all >>> resources etc associated with o-1 will be released (unless they >>are >>> also needed for o-2, that is). >>> >>> Does it mean that the browser is just capable of having *one* >>> multimedia session at the same time? Well, in SIP world this >>typically >>> means putting on-hold the previous call so, indeed, resources >>would be >>> released. >>> >>> But, why couldn't the browser send a just-audio offer somewhere >>and a >>> just-video offer to other destination at the same time? >>> >>> -- >>> I=F1aki Baz Castillo >>> > >>> _______________________________________________ >>> 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 >> >> >>-- >>Randell Jesup >>randell-ietf@jesup.org >>_______________________________________________ >>rtcweb mailing list >>rtcweb@ietf.org >>https://www.ietf.org/mailman/listinfo/rtcweb From richard.ejzak@alcatel-lucent.com Tue Feb 21 15:03: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 C8DBF11E8118 for ; Tue, 21 Feb 2012 15:03:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.324 X-Spam-Level: X-Spam-Status: No, score=-6.324 tagged_above=-999 required=5 tests=[AWL=-0.726, BAYES_00=-2.599, GB_SUMOF=5, 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 3O3gqsUNPnH4 for ; Tue, 21 Feb 2012 15:03:02 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id CAF7411E8116 for ; Tue, 21 Feb 2012 15:02:59 -0800 (PST) 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 q1LN2v9X013285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 Feb 2012 17:02:58 -0600 (CST) 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 q1LN2vG0010869 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 21 Feb 2012 17:02:57 -0600 Received: from USNAVSXCHMBSA1.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Tue, 21 Feb 2012 17:02:57 -0600 From: "Ejzak, Richard P (Richard)" To: Roman Shpount , Cary W FitzGerald Date: Tue, 21 Feb 2012 17:02:56 -0600 Thread-Topic: [rtcweb] Consensus call on JSEP/ROAP Thread-Index: Aczw6KwzCTB+OGGBSl2lmjyPPXBEvwAApvhg Message-ID: <6F428EFD2B8C2F49A2FB1317291A76C11355D4A12E@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> References: <6F428EFD2B8C2F49A2FB1317291A76C11355D49DF5@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <005BC7E2-88EE-4D8F-8AEA-4614D39A6DC6@employees.org> 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_6F428EFD2B8C2F49A2FB1317291A76C11355D4A12EUSNAVSXCHMBSA_" 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 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consensus call on JSEP/ROAP 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, 21 Feb 2012 23:03:07 -0000 --_000_6F428EFD2B8C2F49A2FB1317291A76C11355D4A12EUSNAVSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Roman, If this issue has already been debated in the group, I must apologize. But= if standards had to accommodate every non-standard implementation in exist= ence then we wouldn't be able to accomplish much... I proposed in another thread that we model this kind of behavior with stand= ard SIP serial forking, which JSEP must be able to support. The SIP isn't = exactly the same, but the offer/answer sequence is. This allows implementa= tions to realize this flow in practice if necessary without encoding it in = our specs. Could this be an acceptable compromise? Richard ________________________________ From: Roman Shpount [mailto:roman@telurix.com] Sent: Tuesday, February 21, 2012 4:32 PM To: Cary W FitzGerald Cc: Ejzak, Richard P (Richard); rtcweb@ietf.org Subject: Re: [rtcweb] Consensus call on JSEP/ROAP Another issue is that real-life SIP deployments are often not RFC 3264 comp= laint. In particular it is not unusual to receive different SDP in provisio= nal and final INVITE response. This does not fit offer/answer model since i= t implies multiple answers to one offer with subsequent answers overwriting= previous ones. So, offer/answer compliance is insufficient even for the SI= P interop. _____________ Roman Shpount On Tue, Feb 21, 2012 at 3:13 PM, Cary W FitzGerald > wrote: This is partially inevitable. For WebRTC applications that interact with S= IP gateways, the WebRTC application can't signal anything that 3264 won't a= llow, since the gateway's side won't be able to deal with it. The original= architecture document http://tools.ietf.org/html/draft-ietf-rtcweb-overvie= w-02 proposes a RTC trapezoid and any well-behaved trapezoid needs to consi= der the SIP case and therefore 3264. There is another important case, which is when the trapezoid degenerates in= to a triangle. This is the case where the web server controls both sides o= f the conversation (e.g. connecting to an attendant at www.ftd.com without any intervening PBX/switch/traditional contact center).= Since there is no PSTN GW to contend with, it's not necessary to obey the= gateway's rules. In this case, the server presumably knows what it's doin= g, so it's probably a bug if it trips itself up. There is potentially a third case, which is where the trapezoid is maintain= ed, and the servers are communicating with some-protocol-not-SIP that doesn= 't need to abide by 3264 (which excludes H.323), but are not smart enough t= o coordinate media between themselves, but this doesn't seem very important= . I could be wrong about that, but I don't see the practical use case. Cary. On Feb 21, 2012, at 8:52 AM, Ejzak, Richard P (Richard) wrote: Hi All, I would like to point out that if you rephrase the question to ask "who pre= fers to base subsequent work on RFC 3264 semantics?", then you would need t= o combine positions 2 and 4, and you would get a vote of 28 (the position 3= votes) for a new semantic model (requiring significant new work on SDP) ag= ainst 21 (the sum of votes for positions 2 and 4) for RFC 3264 semantics. So while I do not object to using JSEP as a basis for further work, it seem= s that the group is far less certain about the on-the-wire semantics to be = associated with it. My preference is to focus on RFC 3264 semantics (notin= g that the low level of the API would still allow considerable flexibility = to support other signaling protocols). My key concern is to have clear rul= es (based on common semantics) for interworking media/transport negotiation= procedures between different on-the-wire protocols to avoid potential inte= rop problems. In particular, at this point in the discussion, I do not see the value of a= llowing multiple open OFFERs within a dialog (which have acknowledged probl= ems), multiple ANSWERs within a dialog, or PRANSWERs, none of which exist i= n RFC 3264. I propose that the group first decide whether to use JSEP as a basis for fu= rther work and in subsequent step(s) decide whether and how to go beyond RF= C 3264 semantics. I see this proposal as simply a clarification of the mea= ning of position 3. Richard Ejzak -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcwe= b-bounces@ietf.org] On Behalf Of Ted Hardie Sent: Tuesday, February 07, 2012 2:25 PM To: rtcweb@ietf.org Subject: [rtcweb] Consensus call on JSEP/ROAP During the interim meeting, the attendees discussed the JSEP and ROAP proposals. The chairs also asked the working group to consider whether they might be successfully merged. Because of audio difficulties, there is no recording available. The jabber logs contain a transcription of the discussion by Bernard Aboba and can be found here: http://www.ietf.org/jabber/logs/rtcweb/2012-01-31.html. At the end of the discussion, the chairs asked the attendees to indicate their preferences by standing for one of four positions, which wer= e listed prior to the question being called. The positions were: 1--Don't care whether ROAP or JSEP is the input document for further work in this area 2---Prefer ROAP be the input document for further work 3--Prefer JSEP be the input document for further work 4--Prefer to merge the docs, limiting JSEP to RFC 3264 offer/answer semanti= cs. The results were: 1=3D9 in room, none in jabber 2=3D11 in room, 2 in jabber 3=3D25 in room, 3 in jabber 4=3D8 in room, none in jabber. Because JSEP supports more than one model of negotiation, choosing 3 is a reversal from previous working group consensus to limit work to the offer/answer model. The chairs are now calling for consensus of the working group on this point. Working group participants who were not present at the interim, please review the input documents if you not have yet done so, and forward your comments to the list. All working group participants are asked to make their points on this topic by February 22nd, so that we have timely input prior to the document deadline for Paris. thanks, Ted Hardie for the Chairs _______________________________________________ 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 --_000_6F428EFD2B8C2F49A2FB1317291A76C11355D4A12EUSNAVSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Roman,

If this issue has already been debated= in the group, I must apologize.  But if standards had to accommodate ever= y non-standard implementation in existence then we wouldn’t be able to accomplish much…

 

I proposed in another thread that we m= odel this kind of behavior with standard SIP serial forking, which JSEP must be = able to support.  The SIP isn’t exactly the same, but the offer/answe= r sequence is.  This allows implementations to realize this flow in prac= tice if necessary without encoding it in our specs.  Could this be an acceptable compromise?

 

Richard

 

From: Roman Sh= pount [mailto:roman@telurix.com]
Sent: Tuesday, February 21, = 2012 4:32 PM
To: Cary W FitzGerald
Cc: Ejzak, Richard P (Richar= d); rtcweb@ietf.org
Subject: Re: [rtcweb] Consen= sus call on JSEP/ROAP

 

Another issue is = that real-life SIP deployments are often not RFC 3264 complaint. In particular i= t is not unusual to receive different SDP in provisional and final INVITE respon= se. This does not fit offer/answer model since it implies multiple answers to o= ne offer with subsequent answers overwriting previous ones. So, offer/answer compliance is insufficient even for the SIP interop.
_____________
Roman Shpount

On Tue, Feb 21, 2012 at 3:13 PM, Cary W FitzGerald <caryfitz@employees.org> wrote= :

This is partially inevitable.  For WebRTC applications that interact with SIP gateways, the WebRTC application can't signal anything th= at 3264 won't allow, since the gateway's side won't be able to deal with it.  The original architecture document http://tools.ietf.org/html/draft-ietf-rtcweb-overview-02 = proposes a RTC trapezoid and any well-behaved trapezoid needs to consider the SIP ca= se and therefore 3264.

 

There is another important case, which is when the trapezoid degenerates into a triangle.  This is the case where the web server controls both sides of the conversation (e.g. connecting to an attendant at= www.ftd.com without any intervening PBX/switch/traditional contact center).  Since there is no PSTN GW to contend with, it's not necessary to obey the gateway's rules.  In this case, the server presumably knows what it's doing, so it's pr= obably a bug if it trips itself up.

 

There is potentially a third case, which is where the trapezoid is maintained, and the servers are communicating with some-protocol-not-SIP th= at doesn't need to abide by 3264 (which excludes H.323), but are not smart eno= ugh to coordinate media between themselves, but this doesn't seem very importan= t.  I could be wrong about that, but I don't see the practical use case.<= o:p>

 

Cary.

 

On Feb 21, 2012, at 8:52 AM, Ejzak, Richard P (Richard) wrote:=



Hi All,
I would like to point out that if you rephrase the question to ask "wh= o prefers to base subsequent work on RFC 3264 semantics?", then you woul= d need to combine positions 2 and 4, and you would get a vote of 28 (the posi= tion 3 votes) for a new semantic model (requiring significant new work on SDP) against 21 (the sum of votes for positions 2 and 4) for RFC 3264 semantics.=

So while I do not object to using JSEP as a basis for further work, it seem= s that the group is far less certain about the on-the-wire semantics to be associated with it.  My preference is to focus on RFC 3264 semantics (noting that the low level of the API would still allow considerable flexibility to support other signaling protocols).  My key concern is = to have clear rules (based on common semantics) for interworking media/transpo= rt negotiation procedures between different on-the-wire protocols to avoid potential interop problems.  

In particular, at this point in the discussion, I do not see the value of allowing multiple open OFFERs within a dialog (which have acknowledged problems), multiple ANSWERs within a dialog, or PRANSWERs, none of which ex= ist in RFC 3264.

I propose that the group first decide whether to use JSEP as a basis for fu= rther work and in subsequent step(s) decide whether and how to go beyond RFC 3264 semantics.  I see this proposal as simply a clarification of the meani= ng of position 3.

Richard Ejzak

-----Original Message-----
From: rtcweb-b= ounces@ietf.org [mailto:rtcweb= -bounces@ietf.org] On Behalf Of Ted Hardie
Sent: Tuesday, February 07, 2012 2:25 PM
To: rtcweb@ietf.org
Subject: [rtcweb] Consensus call on JSEP/ROAP

During the interim meeting, the attendees discussed the JSEP and ROAP
proposals.  The chairs also asked the working group to consider
whether they might be successfully merged.  Because of audio difficult= ies,
there is no recording available.  The jabber logs contain
a transcription of the discussion by Bernard Aboba and can be found
here: http://www.ietf.org/jabber/logs/rtcweb/2012-01-31.html.

At the end of the discussion, the chairs asked the attendees to
indicate their preferences by standing for one of four positions, which wer= e
listed prior to the question being called.  The positions were:

1--Don't care whether ROAP or JSEP is the input document for further
work in this area

2---Prefer ROAP be the input document for further work

3--Prefer JSEP be the input document for further work

4--Prefer to merge the docs, limiting JSEP to RFC 3264 offer/answer semanti= cs.

The results were: 1=3D9 in room, none in jabber
            &nb= sp;            =    2=3D11 in room, 2 in jabber
            &nb= sp;            =    3=3D25 in room, 3 in jabber
            &nb= sp;            =    4=3D8 in room, none in jabber.

Because JSEP supports more than one model of negotiation, choosing 3
is a reversal  from previous working group consensus to limit work to<= br> the offer/answer model.

The chairs are now calling for consensus of the working group on this
point.  Working group participants who were not present at the interim= ,
please review the input documents if you not have yet done so, and
forward your comments to the list.  All working group participants are=
asked to make
their points on this topic by February 22nd, so that we have timely
input prior to the document deadline for Paris.

thanks,

Ted Hardie for the Chairs
_______________________________________________
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

 

--_000_6F428EFD2B8C2F49A2FB1317291A76C11355D4A12EUSNAVSXCHMBSA_-- From roman@telurix.com Tue Feb 21 15:18: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 D14C111E80BC for ; Tue, 21 Feb 2012 15:18:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.283 X-Spam-Level: X-Spam-Status: No, score=-0.283 tagged_above=-999 required=5 tests=[AWL=-2.307, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_SUMOF=5, 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 S7OWGUnRF5fX for ; Tue, 21 Feb 2012 15:18:34 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3A14211E8088 for ; Tue, 21 Feb 2012 15:18:34 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so8229689pbc.31 for ; Tue, 21 Feb 2012 15:18:34 -0800 (PST) Received-SPF: pass (google.com: domain of roman@telurix.com designates 10.68.74.138 as permitted sender) client-ip=10.68.74.138; Authentication-Results: mr.google.com; spf=pass (google.com: domain of roman@telurix.com designates 10.68.74.138 as permitted sender) smtp.mail=roman@telurix.com Received: from mr.google.com ([10.68.74.138]) by 10.68.74.138 with SMTP id t10mr81524259pbv.126.1329866314115 (num_hops = 1); Tue, 21 Feb 2012 15:18:34 -0800 (PST) Received: by 10.68.74.138 with SMTP id t10mr67082517pbv.126.1329866313871; Tue, 21 Feb 2012 15:18:33 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id x1sm17204957pbp.50.2012.02.21.15.18.32 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Feb 2012 15:18:33 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so8229672pbc.31 for ; Tue, 21 Feb 2012 15:18:32 -0800 (PST) Received-SPF: pass (google.com: domain of roman@telurix.com designates 10.68.208.196 as permitted sender) client-ip=10.68.208.196; Received: from mr.google.com ([10.68.208.196]) by 10.68.208.196 with SMTP id mg4mr81871558pbc.108.1329866312180 (num_hops = 1); Tue, 21 Feb 2012 15:18:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.208.196 with SMTP id mg4mr67436450pbc.108.1329866312160; Tue, 21 Feb 2012 15:18:32 -0800 (PST) Received: by 10.68.130.132 with HTTP; Tue, 21 Feb 2012 15:18:32 -0800 (PST) In-Reply-To: <6F428EFD2B8C2F49A2FB1317291A76C11355D4A12E@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> References: <6F428EFD2B8C2F49A2FB1317291A76C11355D49DF5@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <005BC7E2-88EE-4D8F-8AEA-4614D39A6DC6@employees.org> <6F428EFD2B8C2F49A2FB1317291A76C11355D4A12E@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> Date: Tue, 21 Feb 2012 18:18:32 -0500 Message-ID: From: Roman Shpount To: "Ejzak, Richard P (Richard)" Content-Type: multipart/alternative; boundary=14dae9c09a9e22973304b981a1d4 X-Gm-Message-State: ALoCoQn3FggkHzdqD0Jmtm1CeFIBY6mcsV/+grg83nR+t0/2eRLCFkTiXn71GVYSa2xUwx1gLegk Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consensus call on JSEP/ROAP 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, 21 Feb 2012 23:18:38 -0000 --14dae9c09a9e22973304b981a1d4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Richard, I must apologize as well, since I know that this issue was discussed before on the list and decision was made to support multiple provisional responses. I am not sure there was a consensus call on it, but it looked like work group decided to implement this in both ROAP and JSEP. I see your point about standards, but unfortunately real life is often different. You proposal in another thread is only an acceptable compromise if parallel forking is supported. If parallel forking is supported, each new provisional SDP can be treated as a new parallel fork and the previous media connection can be discarded. _____________ Roman Shpount On Tue, Feb 21, 2012 at 6:02 PM, Ejzak, Richard P (Richard) < richard.ejzak@alcatel-lucent.com> wrote: > ** ** > > Hi Roman,**** > > If this issue has already been debated in the group, I must apologize. > But if standards had to accommodate every non-standard implementation in > existence then we wouldn=92t be able to accomplish much=85**** > > ** ** > > I proposed in another thread that we model this kind of behavior with > standard SIP serial forking, which JSEP must be able to support. The SIP > isn=92t exactly the same, but the offer/answer sequence is. This allows > implementations to realize this flow in practice if necessary without > encoding it in our specs. Could this be an acceptable compromise?**** > > ** ** > > Richard**** > > ** ** > ------------------------------ > > *From:* Roman Shpount [mailto:roman@telurix.com] > *Sent:* Tuesday, February 21, 2012 4:32 PM > *To:* Cary W FitzGerald > *Cc:* Ejzak, Richard P (Richard); rtcweb@ietf.org > *Subject:* Re: [rtcweb] Consensus call on JSEP/ROAP**** > > ** ** > > Another issue is that real-life SIP deployments are often not RFC 3264 > complaint. In particular it is not unusual to receive different SDP in > provisional and final INVITE response. This does not fit offer/answer mod= el > since it implies multiple answers to one offer with subsequent answers > overwriting previous ones. So, offer/answer compliance is insufficient ev= en > for the SIP interop. > _____________ > Roman Shpount > > **** > > On Tue, Feb 21, 2012 at 3:13 PM, Cary W FitzGerald > wrote:**** > > This is partially inevitable. For WebRTC applications that interact with > SIP gateways, the WebRTC application can't signal anything that 3264 won'= t > allow, since the gateway's side won't be able to deal with it. The > original architecture document > http://tools.ietf.org/html/draft-ietf-rtcweb-overview-02 proposes a RTC > trapezoid and any well-behaved trapezoid needs to consider the SIP case a= nd > therefore 3264.**** > > ** ** > > There is another important case, which is when the trapezoid degenerates > into a triangle. This is the case where the web server controls both sid= es > of the conversation (e.g. connecting to an attendant at www.ftd.comwithou= t any intervening PBX/switch/traditional contact center). Since > there is no PSTN GW to contend with, it's not necessary to obey the > gateway's rules. In this case, the server presumably knows what it's > doing, so it's probably a bug if it trips itself up.**** > > ** ** > > There is potentially a third case, which is where the trapezoid is > maintained, and the servers are communicating with some-protocol-not-SIP > that doesn't need to abide by 3264 (which excludes H.323), but are not > smart enough to coordinate media between themselves, but this doesn't see= m > very important. I could be wrong about that, but I don't see the practic= al > use case.**** > > ** ** > > ****Cary****.**** > > ** ** > > On Feb 21, 2012, at 8:52 AM, Ejzak, Richard P (Richard) wrote:**** > > > > **** > > Hi All, > I would like to point out that if you rephrase the question to ask "who > prefers to base subsequent work on RFC 3264 semantics?", then you would > need to combine positions 2 and 4, and you would get a vote of 28 (the > position 3 votes) for a new semantic model (requiring significant new wor= k > on SDP) against 21 (the sum of votes for positions 2 and 4) for RFC 3264 > semantics. > > So while I do not object to using JSEP as a basis for further work, it > seems that the group is far less certain about the on-the-wire semantics = to > be associated with it. My preference is to focus on RFC 3264 semantics > (noting that the low level of the API would still allow considerable > flexibility to support other signaling protocols). My key concern is to > have clear rules (based on common semantics) for interworking > media/transport negotiation procedures between different on-the-wire > protocols to avoid potential interop problems. > > In particular, at this point in the discussion, I do not see the value of > allowing multiple open OFFERs within a dialog (which have acknowledged > problems), multiple ANSWERs within a dialog, or PRANSWERs, none of which > exist in RFC 3264. > > I propose that the group first decide whether to use JSEP as a basis for > further work and in subsequent step(s) decide whether and how to go beyon= d > RFC 3264 semantics. I see this proposal as simply a clarification of the > meaning of position 3. > > Richard Ejzak > > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf > Of Ted Hardie > Sent: Tuesday, February 07, 2012 2:25 PM > To: rtcweb@ietf.org > Subject: [rtcweb] Consensus call on JSEP/ROAP > > During the interim meeting, the attendees discussed the JSEP and ROAP > proposals. The chairs also asked the working group to consider > whether they might be successfully merged. Because of audio difficulties= , > there is no recording available. The jabber logs contain > a transcription of the discussion by Bernard Aboba and can be found > here: http://www.ietf.org/jabber/logs/rtcweb/2012-01-31.html. > > At the end of the discussion, the chairs asked the attendees to > indicate their preferences by standing for one of four positions, which > were > listed prior to the question being called. The positions were: > > 1--Don't care whether ROAP or JSEP is the input document for further > work in this area > > 2---Prefer ROAP be the input document for further work > > 3--Prefer JSEP be the input document for further work > > 4--Prefer to merge the docs, limiting JSEP to RFC 3264 offer/answer > semantics. > > The results were: 1=3D9 in room, none in jabber > 2=3D11 in room, 2 in jabber > 3=3D25 in room, 3 in jabber > 4=3D8 in room, none in jabber. > > Because JSEP supports more than one model of negotiation, choosing 3 > is a reversal from previous working group consensus to limit work to > the offer/answer model. > > The chairs are now calling for consensus of the working group on this > point. Working group participants who were not present at the interim, > please review the input documents if you not have yet done so, and > forward your comments to the list. All working group participants are > asked to make > their points on this topic by February 22nd, so that we have timely > input prior to the document deadline for ****Paris****. > > thanks, > > Ted Hardie for the Chairs > _______________________________________________ > 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**** > > ** ** > --14dae9c09a9e22973304b981a1d4 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Richard,

I must apologize as well, since I know that this issue w= as discussed before on the list and decision was made to support multiple p= rovisional responses. I am not sure there was a consensus call on it, but i= t looked like work group decided to implement this in both ROAP and JSEP. I= see your point about standards, but unfortunately real life is often diffe= rent.

You proposal in another thread is only an acceptable compromise if para= llel forking is supported. If parallel forking is supported, each new provi= sional SDP can be treated as a new parallel fork and the previous media con= nection can be discarded.
_____________
Roman Shpount


On Tue, Feb 21, 2012 at 6:02 PM, Ejzak, = Richard P (Richard) <richard.ejzak@alcatel-lucent.com> wrote:

Hi Roman,

If this issue has already bee= n debated in the group, I must apologize. =A0But if standards had to accommodate every non-standard implementation in existence then we wouldn=92t be able to accomplish much=85

=A0

I proposed in another thread = that we model this kind of behavior with standard SIP serial forking, which JSEP must be = able to support. =A0The SIP isn=92t exactly the same, but the offer/answer sequence is. =A0This allows implementations to realize this flow in practic= e if necessary without encoding it in our specs.=A0 Could this be an acceptable compromise?

=A0

Richard<= /font>

=A0

From: Roman Shpo= unt [mailto:roman@teluri= x.com]
Sent: Tuesday, February 21, = 2012 4:32 PM
To: Cary W FitzGerald
Cc: Ejzak, Richard P (Richar= d); rtcweb@ietf.org Subject: Re: [rtcweb] Consen= sus call on JSEP/ROAP

=A0

Another issue is that real-life SIP deployments are often not RFC 3264 complaint. In particular i= t is not unusual to receive different SDP in provisional and final INVITE respon= se. This does not fit offer/answer model since it implies multiple answers to o= ne offer with subsequent answers overwriting previous ones. So, offer/answer compliance is insufficient even for the SIP interop.
_____________
Roman Shpount

On Tue, Feb 21, 2012 at 3:13 PM, Cary W FitzGerald &= lt;caryfitz@emp= loyees.org> wrote:

This is partially inevitable. =A0For WebRTC applicat= ions that interact with SIP gateways, the WebRTC application can't signal anythin= g that 3264 won't allow, since the gateway's side won't be able to dea= l with it. =A0The original architecture document=A0http://tools.ietf.org/h= tml/draft-ietf-rtcweb-overview-02=A0proposes a RTC trapezoid and any well-behaved trapezoid needs to consider the SIP ca= se and therefore 3264.

=A0

There is another important case, which is when the t= rapezoid degenerates into a triangle. =A0This is the case where the web server controls both sides of the conversation (e.g. connecting to an attendant at= www.ftd.com without a= ny intervening PBX/switch/traditional contact center). =A0Since there is no PSTN GW to contend with, it's not necessary to obey the gateway's r= ules. =A0In this case, the server presumably knows what it's doing, so it'= ;s probably a bug if it trips itself up.

=A0

There is potentially a third case, which is where th= e trapezoid is maintained, and the servers are communicating with some-protocol-not-SIP th= at doesn't need to abide by 3264 (which excludes H.323), but are not smart= enough to coordinate media between themselves, but this doesn't seem very impo= rtant. =A0I could be wrong about that, but I don't see the practical use case.=

=A0

Cary.

=A0

On Feb 21, 2012, at 8:52 AM, Ejzak, Richard P (Richa= rd) wrote:



Hi All,
I would like to point out that if you rephrase the question to ask "wh= o prefers to base subsequent work on RFC 3264 semantics?", then you woul= d need to combine positions 2 and 4, and you would get a vote of 28 (the posi= tion 3 votes) for a new semantic model (requiring significant new work on SDP) against 21 (the sum of votes for positions 2 and 4) for RFC 3264 semantics.=

So while I do not object to using JSEP as a basis for further work, it seem= s that the group is far less certain about the on-the-wire semantics to be associated with it. =A0My preference is to focus on RFC 3264 semantics (noting that the low level of the API would still allow considerable flexibility to support other signaling protocols). =A0My key concern is to have clear rules (based on common semantics) for interworking media/transpo= rt negotiation procedures between different on-the-wire protocols to avoid potential interop problems. =A0

In particular, at this point in the discussion, I do not see the value of allowing multiple open OFFERs within a dialog (which have acknowledged problems), multiple ANSWERs within a dialog, or PRANSWERs, none of which ex= ist in RFC 3264.

I propose that the group first decide whether to use JSEP as a basis for fu= rther work and in subsequent step(s) decide whether and how to go beyond RFC 3264 semantics. =A0I see this proposal as simply a clarification of the meaning of position 3.

Richard Ejzak

-----Original Message-----
From: rtcweb-b= ounces@ietf.org [mailto:rtcweb= -bounces@ietf.org] On Behalf Of Ted Hardie
Sent: Tuesday, February 07, 2012 2:25 PM
To: rtcweb@ietf.org
Subject: [rtcweb] Consensus call on JSEP/ROAP

During the interim meeting, the attendees discussed the JSEP and ROAP
proposals. =A0The chairs also asked the working group to consider
whether they might be successfully merged. =A0Because of audio difficulties= ,
there is no recording available. =A0The jabber logs contain
a transcription of the discussion by Bernard Aboba and can be found
here: http://www.ietf.org/jabber/logs/rtcweb/2012-01-31.html.=

At the end of the discussion, the chairs asked the attendees to
indicate their preferences by standing for one of four positions, which wer= e
listed prior to the question being called. =A0The positions were:

1--Don't care whether ROAP or JSEP is the input document for further work in this area

2---Prefer ROAP be the input document for further work

3--Prefer JSEP be the input document for further work

4--Prefer to merge the docs, limiting JSEP to RFC 3264 offer/answer semanti= cs.

The results were: 1=3D9 in room, none in jabber
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A02=3D11 in room, 2 in jabber
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A03=3D25 in room, 3 in jabber
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A04=3D8 in room, none in jabber.

Because JSEP supports more than one model of negotiation, choosing 3
is a reversal =A0from previous working group consensus to limit work to
the offer/answer model.

The chairs are now calling for consensus of the working group on this
point. =A0Working group participants who were not present at the interim, please review the input documents if you not have yet done so, and
forward your comments to the list. =A0All working group participants are asked to make
their points on this topic by February 22nd, so that we have timely
input prior to the document deadline for Paris.=

thanks,

Ted Hardie for the Chairs
_______________________________________________
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

=A0


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

=A0


--14dae9c09a9e22973304b981a1d4-- From richard.ejzak@alcatel-lucent.com Tue Feb 21 15:41: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 97F2C21E8038 for ; Tue, 21 Feb 2012 15:41:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.178 X-Spam-Level: X-Spam-Status: No, score=-6.178 tagged_above=-999 required=5 tests=[AWL=-0.580, BAYES_00=-2.599, GB_SUMOF=5, 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 Ixih1GXVKLWS for ; Tue, 21 Feb 2012 15:41:02 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id F3E7D21E8047 for ; Tue, 21 Feb 2012 15:40:35 -0800 (PST) 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 q1LNeY6V024915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 Feb 2012 17:40:34 -0600 (CST) 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 q1LNeXak025954 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 21 Feb 2012 17:40:33 -0600 Received: from USNAVSXCHMBSA1.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Tue, 21 Feb 2012 17:40:33 -0600 From: "Ejzak, Richard P (Richard)" To: Roman Shpount Date: Tue, 21 Feb 2012 17:40:32 -0600 Thread-Topic: [rtcweb] Consensus call on JSEP/ROAP Thread-Index: Aczw7yTmyT9wHpsrS/qHnxY0AWb/YwAAf/6g Message-ID: <6F428EFD2B8C2F49A2FB1317291A76C11355D4A14E@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> References: <6F428EFD2B8C2F49A2FB1317291A76C11355D49DF5@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <005BC7E2-88EE-4D8F-8AEA-4614D39A6DC6@employees.org> <6F428EFD2B8C2F49A2FB1317291A76C11355D4A12E@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_6F428EFD2B8C2F49A2FB1317291A76C11355D4A14EUSNAVSXCHMBSA_" 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 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consensus call on JSEP/ROAP 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, 21 Feb 2012 23:41:07 -0000 --_000_6F428EFD2B8C2F49A2FB1317291A76C11355D4A14EUSNAVSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Roman, You are correct that parallel forking is needed to model this case. I mean= t to distinguish between cases where the previous dialog is cleared immedia= tely upon receipt of a new dialog, compared to the case where multiple dial= ogs are maintained in parallel, and I messed up. Thanks. Richard ________________________________ From: Roman Shpount [mailto:roman@telurix.com] Sent: Tuesday, February 21, 2012 5:19 PM To: Ejzak, Richard P (Richard) Cc: Cary W FitzGerald; rtcweb@ietf.org Subject: Re: [rtcweb] Consensus call on JSEP/ROAP Hi Richard, I must apologize as well, since I know that this issue was discussed before= on the list and decision was made to support multiple provisional response= s. I am not sure there was a consensus call on it, but it looked like work = group decided to implement this in both ROAP and JSEP. I see your point abo= ut standards, but unfortunately real life is often different. You proposal in another thread is only an acceptable compromise if parallel= forking is supported. If parallel forking is supported, each new provision= al SDP can be treated as a new parallel fork and the previous media connect= ion can be discarded. _____________ Roman Shpount On Tue, Feb 21, 2012 at 6:02 PM, Ejzak, Richard P (Richard) > wrote: Hi Roman, If this issue has already been debated in the group, I must apologize. But= if standards had to accommodate every non-standard implementation in exist= ence then we wouldn't be able to accomplish much... I proposed in another thread that we model this kind of behavior with stand= ard SIP serial forking, which JSEP must be able to support. The SIP isn't = exactly the same, but the offer/answer sequence is. This allows implementa= tions to realize this flow in practice if necessary without encoding it in = our specs. Could this be an acceptable compromise? Richard ________________________________ From: Roman Shpount [mailto:roman@telurix.com] Sent: Tuesday, February 21, 2012 4:32 PM To: Cary W FitzGerald Cc: Ejzak, Richard P (Richard); rtcweb@ietf.org Subject: Re: [rtcweb] Consensus call on JSEP/ROAP Another issue is that real-life SIP deployments are often not RFC 3264 comp= laint. In particular it is not unusual to receive different SDP in provisio= nal and final INVITE response. This does not fit offer/answer model since i= t implies multiple answers to one offer with subsequent answers overwriting= previous ones. So, offer/answer compliance is insufficient even for the SI= P interop. _____________ Roman Shpount On Tue, Feb 21, 2012 at 3:13 PM, Cary W FitzGerald > wrote: This is partially inevitable. For WebRTC applications that interact with S= IP gateways, the WebRTC application can't signal anything that 3264 won't a= llow, since the gateway's side won't be able to deal with it. The original= architecture document http://tools.ietf.org/html/draft-ietf-rtcweb-overvie= w-02 proposes a RTC trapezoid and any well-behaved trapezoid needs to consi= der the SIP case and therefore 3264. There is another important case, which is when the trapezoid degenerates in= to a triangle. This is the case where the web server controls both sides o= f the conversation (e.g. connecting to an attendant at www.ftd.com without any intervening PBX/switch/traditional contact center).= Since there is no PSTN GW to contend with, it's not necessary to obey the= gateway's rules. In this case, the server presumably knows what it's doin= g, so it's probably a bug if it trips itself up. There is potentially a third case, which is where the trapezoid is maintain= ed, and the servers are communicating with some-protocol-not-SIP that doesn= 't need to abide by 3264 (which excludes H.323), but are not smart enough t= o coordinate media between themselves, but this doesn't seem very important= . I could be wrong about that, but I don't see the practical use case. Cary. On Feb 21, 2012, at 8:52 AM, Ejzak, Richard P (Richard) wrote: Hi All, I would like to point out that if you rephrase the question to ask "who pre= fers to base subsequent work on RFC 3264 semantics?", then you would need t= o combine positions 2 and 4, and you would get a vote of 28 (the position 3= votes) for a new semantic model (requiring significant new work on SDP) ag= ainst 21 (the sum of votes for positions 2 and 4) for RFC 3264 semantics. So while I do not object to using JSEP as a basis for further work, it seem= s that the group is far less certain about the on-the-wire semantics to be = associated with it. My preference is to focus on RFC 3264 semantics (notin= g that the low level of the API would still allow considerable flexibility = to support other signaling protocols). My key concern is to have clear rul= es (based on common semantics) for interworking media/transport negotiation= procedures between different on-the-wire protocols to avoid potential inte= rop problems. In particular, at this point in the discussion, I do not see the value of a= llowing multiple open OFFERs within a dialog (which have acknowledged probl= ems), multiple ANSWERs within a dialog, or PRANSWERs, none of which exist i= n RFC 3264. I propose that the group first decide whether to use JSEP as a basis for fu= rther work and in subsequent step(s) decide whether and how to go beyond RF= C 3264 semantics. I see this proposal as simply a clarification of the mea= ning of position 3. Richard Ejzak -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcwe= b-bounces@ietf.org] On Behalf Of Ted Hardie Sent: Tuesday, February 07, 2012 2:25 PM To: rtcweb@ietf.org Subject: [rtcweb] Consensus call on JSEP/ROAP During the interim meeting, the attendees discussed the JSEP and ROAP proposals. The chairs also asked the working group to consider whether they might be successfully merged. Because of audio difficulties, there is no recording available. The jabber logs contain a transcription of the discussion by Bernard Aboba and can be found here: http://www.ietf.org/jabber/logs/rtcweb/2012-01-31.html. At the end of the discussion, the chairs asked the attendees to indicate their preferences by standing for one of four positions, which wer= e listed prior to the question being called. The positions were: 1--Don't care whether ROAP or JSEP is the input document for further work in this area 2---Prefer ROAP be the input document for further work 3--Prefer JSEP be the input document for further work 4--Prefer to merge the docs, limiting JSEP to RFC 3264 offer/answer semanti= cs. The results were: 1=3D9 in room, none in jabber 2=3D11 in room, 2 in jabber 3=3D25 in room, 3 in jabber 4=3D8 in room, none in jabber. Because JSEP supports more than one model of negotiation, choosing 3 is a reversal from previous working group consensus to limit work to the offer/answer model. The chairs are now calling for consensus of the working group on this point. Working group participants who were not present at the interim, please review the input documents if you not have yet done so, and forward your comments to the list. All working group participants are asked to make their points on this topic by February 22nd, so that we have timely input prior to the document deadline for Paris. thanks, Ted Hardie for the Chairs _______________________________________________ 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 --_000_6F428EFD2B8C2F49A2FB1317291A76C11355D4A14EUSNAVSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Roman,

You are correct that parallel forking = is needed to model this case.  I meant to distinguish between cases where= the previous dialog is cleared immediately upon receipt of a new dialog, compar= ed to the case where multiple dialogs are maintained in parallel, and I messed= up.  Thanks.

 

Richard

 

From: Roman Sh= pount [mailto:roman@telurix.com]
Sent: Tuesday, February 21, = 2012 5:19 PM
To: Ejzak, Richard P (Richar= d)
Cc: Cary W FitzGerald; rtcweb@ietf.org
Subject: Re: [rtcweb] Consen= sus call on JSEP/ROAP

 

Hi Richard,

I must apologize as well, since I know that this issue was discussed before= on the list and decision was made to support multiple provisional responses. I= am not sure there was a consensus call on it, but it looked like work group decided to implement this in both ROAP and JSEP. I see your point about standards, but unfortunately real life is often different.

You proposal in another thread is only an acceptable compromise if parallel forking is supported. If parallel forking is supported, each new provisiona= l SDP can be treated as a new parallel fork and the previous media connection= can be discarded.
_____________
Roman Shpount

On Tue, Feb 21, 2012 at 6:02 PM, Ejzak, Richard P (Richard) <richard.ejzak@alcatel-luce= nt.com> wrote:

Hi Roman,

If this issue has already been debated in the group, I must apologize.  But if standards had to accommodate every non-standard implementation in existence then we wouldn’t be able to accomplish much…

 

I proposed in another thread that we model this kind of behavio= r with standard SIP serial forking, which JSEP must be able to support.  = ;The SIP isn’t exactly the same, but the offer/answer sequence is.  T= his allows implementations to realize this flow in practice if necessary withou= t encoding it in our specs.  Could this be an acceptable compromise?

 

Richard

 

From: Roman Shpount [mailto:roman@telurix.com] =
Sent: Tuesday, February 21, = 2012 4:32 PM
To: Cary W FitzGerald
Cc: Ejzak, Richard P (Richar= d); rtcweb@ietf.org
Subject: Re: [rtcweb] Consen= sus call on JSEP/ROAP

 

Another = issue is that real-life SIP deployments are often not RFC 3264 complaint. In particu= lar it is not unusual to receive different SDP in provisional and final INVITE response. This does not fit offer/answer model since it implies multiple answers to one offer with subsequent answers overwriting previous ones. So, offer/answer compliance is insufficient even for the SIP interop.
_____________
Roman Shpount

On Tue, = Feb 21, 2012 at 3:13 PM, Cary W FitzGerald <caryfitz@employees.org> wrote:

This is = partially inevitable.  For WebRTC applications that interact with SIP gateways, = the WebRTC application can't signal anything that 3264 won't allow, since the gateway's side won't be able to deal with it.  The original architectu= re document http://tools.ietf.org/html/draft-ietf-rtcweb-overview-02<= /a> proposes a RTC trapezoid and any well-behaved trapezoid needs to consider the SIP ca= se and therefore 3264.

 

There is= another important case, which is when the trapezoid degenerates into a triangle.  This is the case where the web server controls both sides of the conv= ersation (e.g. connecting to an attendant at www.ftd.com without any intervening PBX/switch/traditional contact center).  Since there is no PSTN GW to contend with, it's not necessary to obey the gateway= 's rules.  In this case, the server presumably knows what it's doing, so = it's probably a bug if it trips itself up.

 

There is potentially a third case, which is where the trapezoid is maintained, and t= he servers are communicating with some-protocol-not-SIP that doesn't need to a= bide by 3264 (which excludes H.323), but are not smart enough to coordinate medi= a between themselves, but this doesn't seem very important.  I could be wrong about that, but I don't see the practical use case.=

 

= Cary.

 

On Feb 2= 1, 2012, at 8:52 AM, Ejzak, Richard P (Richard) wrote:

&nb= sp;

Hi All,<= br> I would like to point out that if you rephrase the question to ask "wh= o prefers to base subsequent work on RFC 3264 semantics?", then you woul= d need to combine positions 2 and 4, and you would get a vote of 28 (the posi= tion 3 votes) for a new semantic model (requiring significant new work on SDP) against 21 (the sum of votes for positions 2 and 4) for RFC 3264 semantics.=

So while I do not object to using JSEP as a basis for further work, it seem= s that the group is far less certain about the on-the-wire semantics to be associated with it.  My preference is to focus on RFC 3264 semantics (noting that the low level of the API would still allow considerable flexibility to support other signaling protocols).  My key concern is = to have clear rules (based on common semantics) for interworking media/transpo= rt negotiation procedures between different on-the-wire protocols to avoid potential interop problems.  

In particular, at this point in the discussion, I do not see the value of allowing multiple open OFFERs within a dialog (which have acknowledged problems), multiple ANSWERs within a dialog, or PRANSWERs, none of which ex= ist in RFC 3264.

I propose that the group first decide whether to use JSEP as a basis for further work and in subsequent step(s) decide whether and how to go beyond = RFC 3264 semantics.  I see this proposal as simply a clarification of the meaning of position 3.

Richard Ejzak

-----Original Message-----
From: rtcweb-b= ounces@ietf.org [mailto:rtcweb= -bounces@ietf.org] On Behalf Of Ted Hardie
Sent: Tuesday, February 07, 2012 2:25 PM
To: rtcweb@ietf.org
Subject: [rtcweb] Consensus call on JSEP/ROAP

During the interim meeting, the attendees discussed the JSEP and ROAP
proposals.  The chairs also asked the working group to consider
whether they might be successfully merged.  Because of audio difficult= ies,
there is no recording available.  The jabber logs contain
a transcription of the discussion by Bernard Aboba and can be found
here: http://www.ietf.org/jabber/logs/rtcweb/2012-01-31.html.

At the end of the discussion, the chairs asked the attendees to
indicate their preferences by standing for one of four positions, which wer= e
listed prior to the question being called.  The positions were:

1--Don't care whether ROAP or JSEP is the input document for further
work in this area

2---Prefer ROAP be the input document for further work

3--Prefer JSEP be the input document for further work

4--Prefer to merge the docs, limiting JSEP to RFC 3264 offer/answer semanti= cs.

The results were: 1=3D9 in room, none in jabber
            &nb= sp;            =    2=3D11 in room, 2 in jabber
            &nb= sp;            =    3=3D25 in room, 3 in jabber
            &nb= sp;            =    4=3D8 in room, none in jabber.

Because JSEP supports more than one model of negotiation, choosing 3
is a reversal  from previous working group consensus to limit work to<= br> the offer/answer model.

The chairs are now calling for consensus of the working group on this
point.  Working group participants who were not present at the interim= ,
please review the input documents if you not have yet done so, and
forward your comments to the list.  All working group participants are=
asked to make
their points on this topic by February 22nd, so that we have timely
input prior to the document deadline for Paris.

thanks,

Ted Hardie for the Chairs
_______________________________________________
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

 

 

--_000_6F428EFD2B8C2F49A2FB1317291A76C11355D4A14EUSNAVSXCHMBSA_-- From pravindran@sonusnet.com Tue Feb 21 19:32: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 3E94421E802D for ; Tue, 21 Feb 2012 19:32:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.241 X-Spam-Level: X-Spam-Status: No, score=-2.241 tagged_above=-999 required=5 tests=[AWL=-0.242, BAYES_00=-2.599, J_CHICKENPOX_65=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 iLLFkfxkYf6b for ; Tue, 21 Feb 2012 19:32:48 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 714A121E8024 for ; Tue, 21 Feb 2012 19:32:47 -0800 (PST) Received: from sonusmail07.sonusnet.com (sonusmail07.sonusnet.com [10.128.32.157]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q1M3XTsE006124; Tue, 21 Feb 2012 22:33:30 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Feb 2012 22:31:29 -0500 Received: from INBA-HUB02.sonusnet.com ([10.70.51.87]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Feb 2012 09:01:43 +0530 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, 22 Feb 2012 09:01:43 +0530 From: "Ravindran, Parthasarathi" To: "Ejzak, Richard P (Richard)" , "rtcweb@ietf.org" , "public-webrtc@w3.org" Thread-Topic: [rtcweb] JSEP-02: New offer and answer to previous offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case] Thread-Index: AQHM8AqE+28vByK84kKxG08H/gll95ZF3BIAgAAASYCAAASXgIAAGTuAgADuMECAAH0N0IAAZRbggAAhZzCAAFDIgA== Date: Wed, 22 Feb 2012 03:31:41 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E041386@inba-mail01.sonusnet.com> References: <7F2072F1E0DE894DA4B517B93C6A05852C3D31BA37@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C3D31BA3A@ESESSCMS0356.eemea.ericsson.se> <4F42C2C7.3060802@jesup.org> <387F9047F55E8C42850AD6B3A7A03C6C0E040FFE@inba-mail01.sonusnet.com> <6F428EFD2B8C2F49A2FB1317291A76C11355D49C4E@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <387F9047F55E8C42850AD6B3A7A03C6C0E0412EB@inba-mail01.sonusnet.com> <6F428EFD2B8C2F49A2FB1317291A76C11355D4A115@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> In-Reply-To: <6F428EFD2B8C2F49A2FB1317291A76C11355D4A115@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 22 Feb 2012 03:31:43.0580 (UTC) FILETIME=[7F62F9C0:01CCF112] Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case] 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, 22 Feb 2012 03:32:49 -0000 Hi Richard, Thanks for your comments. I have put the focus on the offer/answer exchange= between OffererJS and OffererUA in the callflow and assumed 18x as reliabl= e. I'm bit afraid to write too much details about SIP in this forum (see RT= CWeb archive for more details) :-) I'll update the callflow with PRACK & 200. Out of the 3 requested usecases,= I have provided 1 and 3 with this assumption. I'll send 2nd usecase of ser= ial forking with UPDATE and updated standard callflow for 1st & 3rd usecase= ASAP. My intention is not to violate standard but I have provided the deployed (r= eal-time) usecases as Cullen requested and also mentioned in the same mail = how to make those callflow standard compliance. For your concern on signali= ng standard deviation discussion within WebRTC, I'll write the separate mai= l. Thanks Partha >-----Original Message----- >From: Ejzak, Richard P (Richard) [mailto:richard.ejzak@alcatel- >lucent.com] >Sent: Wednesday, February 22, 2012 4:15 AM >To: Ravindran, Parthasarathi; rtcweb@ietf.org; public-webrtc@w3.org >Subject: RE: [rtcweb] JSEP-02: New offer and answer to previous offer >[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] > >Hi Partha, >Thanks for the call flows and explanations. > >For all of your flows, it would really help if any deviation from RFC >3261 or RFC 3264 is clearly noted in your flows. Further, it would help >to be clear when you assume reliable or unreliable provisionals, since >that makes a big difference. You appear to usually assume reliable >provisionals, but I want to be sure. > >It would also help to identify the purpose of some key operations in >each flow when not strictly for protocol conformance. For example, >setting some flows to "inactive" is used to avoid having multiple media >flows when parallel forking, but this is an application choice rather >than a protocol necessity. > >You state that your earlier flow violates RFC 3261, and in an earlier >posting you insist that it should be supported because some >implementations behave that way. I have a real problem with this. >Standards are meant to help in avoiding exactly this kind of situation >and I don't think that non-standard behavior should be condoned by >rtcweb. If there is good reason to support this kind of flow then it >should be brought to the appropriate working group for consideration >(not rtcweb). An endpoint could achieve similar behavior by mimicking >standard serial forking procedures (which is what I thought you intended >but you forgot to include the interim final responses or byes). Why not >just use a sequence of UPDATEs and avoid these hassles? > >The three use cases I had in mind were: > >1) mimicking standard serial forking from a single endpoint to realize >the equivalent of multiple ANSWERs to a single OFFER (although separate >OFFER/ANSWER transactions using UPDATE would be cleaner) >2) standard serial forking (with optional UPDATEs) >3) standard parallel forking (with optional UPDATEs) > >Do we really need anything other than 2) and 3)? > >Richard > >-----Original Message----- >From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] >Sent: Tuesday, February 21, 2012 2:51 PM >To: Ejzak, Richard P (Richard); rtcweb@ietf.org; public-webrtc@w3.org; >Randell Jesup >Subject: RE: [rtcweb] JSEP-02: New offer and answer to previous offer >[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] > >Hi all, > >Till now, I'm writing the callflow with the assumption of browser as RTP >Endpoint. Two JSEP example call flow are attached: > > 1) Two 180 with SDP (answer) and second 180's dialog comes up with >2xx with SDP > 2) Two 180 with SDP (answer) and first 180's dialog comes up with >2xx with SDP > >The above callflows are not the only way to solve the problem but it is >one of the way to solve this callflow. The intention of these callflows >are to indicate that multiple answers support in JSEP facilities for >designing SIP parallel forking kind of services. The exact intention is >as per http://www.ietf.org/mail-archive/web/rtcweb/current/msg03455.html >and as follows: > >1) allow a setRemoteDesc(SDP_ANSWER) to follow a >setRemoteDesc(SDP_ANSWER) >2) document that in this case (multiple 2xx), the JS is responsible for >sending BYE to the previous answerer. > >Please let me know your comments on the callflow. > >Hi Richard, > >Thanks for your clarification in the below mail. Please read inline for >more comments > >Thanks >Partha > >>-----Original Message----- >>From: Ejzak, Richard P (Richard) [mailto:richard.ejzak@alcatel- >>lucent.com] >>Sent: Tuesday, February 21, 2012 8:05 PM >>To: Ravindran, Parthasarathi; rtcweb@ietf.org; public-webrtc@w3.org >>Subject: RE: [rtcweb] JSEP-02: New offer and answer to previous offer >>[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] >> >>Hi Partha, >>Regarding my earlier email (this earlier email was not distributed on >>the webrtc list), I do not dispute that forking must be supported by >>all SIP endpoints. Let me rephrase my earlier questions in light of >>your latest call flow. >> >>Looking at your call flow, I see that you treat the case of multiple >>answers from the same endpoint as a serial forking case (or do I >>misunderstand your intent?). > > I agree that this callflow is allowed in JSEP and it is a >violation of RFC 3261 and not RFC 3264. I explained in detail why this >callflow shall be allowed in http://www.ietf.org/mail- >archive/web/rtcweb/current/msg03478.html > > How do you determine that this is a >>special type of serial forking and not a parallel forking case? > > I won't determine it. I will just update based on the last >active answer. > > We have >>at least three use cases for multiple ANSWER and it would be helpful to >>see how they can be handled and distinguished in SIP signaling. >> > Please mentioned the three of them. I'll provide the callflow >for the same > >>Also, PRANSWER as currently defined seems to have no analog in SIP. Is >>this also your understanding? > We have the common understanding here. I'm requesting to remove >PR_ANSWER state as it complicates JS Offer/Answer FSM still more (See: >http://www.ietf.org/mail-archive/web/rtcweb/current/msg03489.html). > > >> >>I don't understand your statement that "It is possible to implement >>parallel forking by keeping only one answer active in the offerer side >>at the given time". It would appear that an implementation of parallel >>forking would need to keep the last answer from each dialog active. >>Please explain. >> > Hope the callflow clarifies > >>I look forward to your next call flow. >> >>Richard >> >>-----Original Message----- >>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >>Behalf Of Ravindran, Parthasarathi >>Sent: Tuesday, February 21, 2012 12:58 AM >>To: Randell Jesup; rtcweb@ietf.org; public-webrtc@w3.org >>Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous offer >>[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] >> >>Randell, >> >>It is possible to implement parallel forking by keeping only one answer >>active in the offerer side at the given time. I attached one of the >>example "18x with SDP and 2xx with different SDP" for your reference >>which will map to serial forking. Please let me know your concern about >>ICE interaction concern here. >> >>I'll send multiple 18x with SDP and one 2xx with SDP response JSEP >>example using UPDATE O/A mechanism ASAP for clarity on parallel forking >>(assumption: multiple answer for single offer is supported in JSEP). >> >>Thanks >>Partha >> >>>-----Original Message----- >>>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >>>Behalf Of Randell Jesup >>>Sent: Tuesday, February 21, 2012 3:32 AM >>>To: rtcweb@ietf.org; public-webrtc@w3.org >>>Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous offer >>>[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] >>> >>>On 2/20/2012 3:31 PM, Roman Shpount wrote: >>>> Not to beat this horse to death, but why is it "suggested not to >>>> have parallel forking"? WebRTC intorduces additional restrictions on >>>> RTP stream (remote media sources and SSRCs are known in advance) >>>> that make parallel forking implementation trivial. Only thing that >>>> is missing is some way to clone the PeerConnection in the API. >>> >>>Right; parallel forking has uses. >>> >>>We've talked about this, but not for a while. One way to implement it >>>would be to on each forked answer clone the state of the >>>PeerConnection as it was with any previous answer removed. However, >>>I'm concerned about how this will interact with the ICE, etc stuff. >>>Someone want to throw out a suggestion? Cullen, Justin - how >>>*should*/*could* forking work within JSEP? >>> >>> >>>Aside on uses of forking: >>>I can see some additional interesting uses for parallel forking, >>>especially in non-phone-like usecases (games among others). The >>>server (or another participant) could hold open an OFFER in order to >>>forward it to any potential new partners. This might apply to a >>>conference call as well if there's a peer-2-peer aspect (mesh, >>>partial-mesh, etc) >>to it. >>> >>>Think in a game or 2nd-life-type-sim, where you're automatically in a >>>voice chat with anyone within hearing range, and those voice chats are >>>done p2p by forking each player's original offer to the server, and >>>forwarding it (forking it) to the new user, who would answer and >>>they'd be in a call. >>> >>>If you wanted to get really fancy, you could even do some of the >>>negotiation in the server and rephrase each offer as an answer to the >>>other side, leading to a 1/2-RTT-to-the-server setup time (more-or- >>less: >>> >>>player 1 server player 2 >>>------------------------------------------------------------ >>>| | | >>>|--> Offer 1 ---------------->| | >>>| |<---------- Offer 2 <----| >>>| | | >>>... >>> Server decides they should talk >>>| | | >>>|<-- Answer(Offer 2) <--------|-----> Answer(Offer 1)-->| >>>|<------------------------- media --------------------->| >>> >>>Even if this is initiated by a player, there are equivalent graphs >>>that use 1/2 RTT (through the server to other player) to set up >channels. >>> >>>I should note however that ICE overhead may well swamp this fancy >>>setup and it may be over-reaching, but each 1/2 RTT removed is >>>significant, so there may be uses. >>> >>>> _____________ >>>> Roman Shpount >>>> >>>> >>>> On Mon, Feb 20, 2012 at 3:14 PM, Christer Holmberg >>>> >>> > >>>> wrote: >>>> >>>> >>>> Hi, >>>> >>>> Just to clarify: the new offer is for the same "session" as the >>>> previous offer, and is supposed to replace the previous offer. >>>> >>>> The browser can of course send a just-audio offer somewhere, and >>a >>>> just-video offer somewhere else, but would those even be >>>associated >>>> with the same PeerConnection? I thought we wanted only one >>>> offer/answer, which is the reason it has been suggested e.g. not >>>to >>>> support paralell forking in the browser. >>>> >>>> Regards, >>>> >>>> Christer >>>> ________________________________________ >>>> From: I=F1aki Baz Castillo [ibc@aliax.net ] >>>> Sent: Monday, February 20, 2012 10:13 PM >>>> To: Christer Holmberg >>>> Cc: Justin Uberti; rtcweb@ietf.org ; >>>> public-webrtc@w3.org >>>> Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous >>>> offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case] >>>> >>>> 2012/2/20 Christer Holmberg >>> >: >>>> > Q1. When the JS app requests the new offer (o-2), I assume >all >>>> resources etc associated with o-1 will be released (unless they >>>are >>>> also needed for o-2, that is). >>>> >>>> Does it mean that the browser is just capable of having *one* >>>> multimedia session at the same time? Well, in SIP world this >>>typically >>>> means putting on-hold the previous call so, indeed, resources >>>would be >>>> released. >>>> >>>> But, why couldn't the browser send a just-audio offer somewhere >>>and a >>>> just-video offer to other destination at the same time? >>>> >>>> -- >>>> I=F1aki Baz Castillo >>>> > >>>> _______________________________________________ >>>> 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 >>> >>> >>>-- >>>Randell Jesup >>>randell-ietf@jesup.org >>>_______________________________________________ >>>rtcweb mailing list >>>rtcweb@ietf.org >>>https://www.ietf.org/mailman/listinfo/rtcweb From christer.holmberg@ericsson.com Wed Feb 22 03:45: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 43AB121F8677 for ; Wed, 22 Feb 2012 03:45:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.791 X-Spam-Level: X-Spam-Status: No, score=-9.791 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, J_CHICKENPOX_65=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 FwicuxBr5cCq for ; Wed, 22 Feb 2012 03:45:57 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 159DE21F866B for ; Wed, 22 Feb 2012 03:45:56 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-4c-4f44d5737c2b Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id EC.55.27041.375D44F4; Wed, 22 Feb 2012 12:45:56 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Wed, 22 Feb 2012 12:45:55 +0100 From: Christer Holmberg To: "Ravindran, Parthasarathi" , "Ejzak, Richard P (Richard)" , "rtcweb@ietf.org" , "public-webrtc@w3.org" Date: Wed, 22 Feb 2012 12:45:54 +0100 Thread-Topic: [rtcweb] JSEP-02: New offer and answer to previous offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case] Thread-Index: AQHM8AqE+28vByK84kKxG08H/gll95ZF3BIAgAAASYCAAASXgIAAGTuAgADuMECAAH0N0IAAZRbggAAhZzCAAFDIgIAAkYmA Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3D915AAA@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C3D31BA37@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C3D31BA3A@ESESSCMS0356.eemea.ericsson.se> <4F42C2C7.3060802@jesup.org> <387F9047F55E8C42850AD6B3A7A03C6C0E040FFE@inba-mail01.sonusnet.com> <6F428EFD2B8C2F49A2FB1317291A76C11355D49C4E@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <387F9047F55E8C42850AD6B3A7A03C6C0E0412EB@inba-mail01.sonusnet.com> <6F428EFD2B8C2F49A2FB1317291A76C11355D4A115@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <387F9047F55E8C42850AD6B3A7A03C6C0E041386@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E041386@inba-mail01.sonusnet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case] 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, 22 Feb 2012 11:45:59 -0000 Hi, Just to clarify: my suggestion has been to support only serial forking for = a given PeerConnection, and for that PeerConnection any new answer would re= place the previous one. If paralell forking in the browser really is needed, one option is to "clon= e" the PeerConnection. Regards, Christer -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Ravindran, Parthasarathi Sent: 22. helmikuuta 2012 5:32 To: Ejzak, Richard P (Richard); rtcweb@ietf.org; public-webrtc@w3.org Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous offer [was:= JSEP-02: SDP_PRANSWER and FEDEX use-case] Hi Richard, Thanks for your comments. I have put the focus on the offer/answer exchange= between OffererJS and OffererUA in the callflow and assumed 18x as reliabl= e. I'm bit afraid to write too much details about SIP in this forum (see RT= CWeb archive for more details) :-) I'll update the callflow with PRACK & 200. Out of the 3 requested usecases,= I have provided 1 and 3 with this assumption. I'll send 2nd usecase of ser= ial forking with UPDATE and updated standard callflow for 1st & 3rd usecase= ASAP. My intention is not to violate standard but I have provided the deployed (r= eal-time) usecases as Cullen requested and also mentioned in the same mail = how to make those callflow standard compliance. For your concern on signali= ng standard deviation discussion within WebRTC, I'll write the separate mai= l. Thanks Partha >-----Original Message----- >From: Ejzak, Richard P (Richard) [mailto:richard.ejzak@alcatel- >lucent.com] >Sent: Wednesday, February 22, 2012 4:15 AM >To: Ravindran, Parthasarathi; rtcweb@ietf.org; public-webrtc@w3.org >Subject: RE: [rtcweb] JSEP-02: New offer and answer to previous offer >[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] > >Hi Partha, >Thanks for the call flows and explanations. > >For all of your flows, it would really help if any deviation from RFC >3261 or RFC 3264 is clearly noted in your flows. Further, it would >help to be clear when you assume reliable or unreliable provisionals, >since that makes a big difference. You appear to usually assume >reliable provisionals, but I want to be sure. > >It would also help to identify the purpose of some key operations in >each flow when not strictly for protocol conformance. For example, >setting some flows to "inactive" is used to avoid having multiple media >flows when parallel forking, but this is an application choice rather >than a protocol necessity. > >You state that your earlier flow violates RFC 3261, and in an earlier >posting you insist that it should be supported because some >implementations behave that way. I have a real problem with this. >Standards are meant to help in avoiding exactly this kind of situation >and I don't think that non-standard behavior should be condoned by >rtcweb. If there is good reason to support this kind of flow then it >should be brought to the appropriate working group for consideration >(not rtcweb). An endpoint could achieve similar behavior by mimicking >standard serial forking procedures (which is what I thought you >intended but you forgot to include the interim final responses or >byes). Why not just use a sequence of UPDATEs and avoid these hassles? > >The three use cases I had in mind were: > >1) mimicking standard serial forking from a single endpoint to realize >the equivalent of multiple ANSWERs to a single OFFER (although separate >OFFER/ANSWER transactions using UPDATE would be cleaner) >2) standard serial forking (with optional UPDATEs) >3) standard parallel forking (with optional UPDATEs) > >Do we really need anything other than 2) and 3)? > >Richard > >-----Original Message----- >From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] >Sent: Tuesday, February 21, 2012 2:51 PM >To: Ejzak, Richard P (Richard); rtcweb@ietf.org; public-webrtc@w3.org; >Randell Jesup >Subject: RE: [rtcweb] JSEP-02: New offer and answer to previous offer >[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] > >Hi all, > >Till now, I'm writing the callflow with the assumption of browser as >RTP Endpoint. Two JSEP example call flow are attached: > > 1) Two 180 with SDP (answer) and second 180's dialog comes up with = 2xx >with SDP > 2) Two 180 with SDP (answer) and first 180's dialog comes up with >2xx with SDP > >The above callflows are not the only way to solve the problem but it is >one of the way to solve this callflow. The intention of these callflows >are to indicate that multiple answers support in JSEP facilities for >designing SIP parallel forking kind of services. The exact intention >is as per >http://www.ietf.org/mail-archive/web/rtcweb/current/msg03455.html >and as follows: > >1) allow a setRemoteDesc(SDP_ANSWER) to follow a >setRemoteDesc(SDP_ANSWER) >2) document that in this case (multiple 2xx), the JS is responsible for >sending BYE to the previous answerer. > >Please let me know your comments on the callflow. > >Hi Richard, > >Thanks for your clarification in the below mail. Please read inline for >more comments > >Thanks >Partha > >>-----Original Message----- >>From: Ejzak, Richard P (Richard) [mailto:richard.ejzak@alcatel- >>lucent.com] >>Sent: Tuesday, February 21, 2012 8:05 PM >>To: Ravindran, Parthasarathi; rtcweb@ietf.org; public-webrtc@w3.org >>Subject: RE: [rtcweb] JSEP-02: New offer and answer to previous offer >>[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] >> >>Hi Partha, >>Regarding my earlier email (this earlier email was not distributed on >>the webrtc list), I do not dispute that forking must be supported by >>all SIP endpoints. Let me rephrase my earlier questions in light of >>your latest call flow. >> >>Looking at your call flow, I see that you treat the case of multiple >>answers from the same endpoint as a serial forking case (or do I >>misunderstand your intent?). > > I agree that this callflow is allowed in JSEP and it is a >violation of RFC 3261 and not RFC 3264. I explained in detail why this >callflow shall be allowed in http://www.ietf.org/mail- >archive/web/rtcweb/current/msg03478.html > > How do you determine that this is a >>special type of serial forking and not a parallel forking case? > > I won't determine it. I will just update based on the last >active answer. > > We have >>at least three use cases for multiple ANSWER and it would be helpful >>to see how they can be handled and distinguished in SIP signaling. >> > Please mentioned the three of them. I'll provide the callflow >for the same > >>Also, PRANSWER as currently defined seems to have no analog in SIP. >>Is this also your understanding? > We have the common understanding here. I'm requesting to >remove PR_ANSWER state as it complicates JS Offer/Answer FSM still more (S= ee: >http://www.ietf.org/mail-archive/web/rtcweb/current/msg03489.html). > > >> >>I don't understand your statement that "It is possible to implement >>parallel forking by keeping only one answer active in the offerer side >>at the given time". It would appear that an implementation of >>parallel forking would need to keep the last answer from each dialog acti= ve. >>Please explain. >> > Hope the callflow clarifies > >>I look forward to your next call flow. >> >>Richard >> >>-----Original Message----- >>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >>Behalf Of Ravindran, Parthasarathi >>Sent: Tuesday, February 21, 2012 12:58 AM >>To: Randell Jesup; rtcweb@ietf.org; public-webrtc@w3.org >>Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous offer >>[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] >> >>Randell, >> >>It is possible to implement parallel forking by keeping only one >>answer active in the offerer side at the given time. I attached one of >>the example "18x with SDP and 2xx with different SDP" for your >>reference which will map to serial forking. Please let me know your >>concern about ICE interaction concern here. >> >>I'll send multiple 18x with SDP and one 2xx with SDP response JSEP >>example using UPDATE O/A mechanism ASAP for clarity on parallel >>forking >>(assumption: multiple answer for single offer is supported in JSEP). >> >>Thanks >>Partha >> >>>-----Original Message----- >>>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >>>Behalf Of Randell Jesup >>>Sent: Tuesday, February 21, 2012 3:32 AM >>>To: rtcweb@ietf.org; public-webrtc@w3.org >>>Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous offer >>>[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] >>> >>>On 2/20/2012 3:31 PM, Roman Shpount wrote: >>>> Not to beat this horse to death, but why is it "suggested not to >>>> have parallel forking"? WebRTC intorduces additional restrictions >>>> on RTP stream (remote media sources and SSRCs are known in advance) >>>> that make parallel forking implementation trivial. Only thing that >>>> is missing is some way to clone the PeerConnection in the API. >>> >>>Right; parallel forking has uses. >>> >>>We've talked about this, but not for a while. One way to implement >>>it would be to on each forked answer clone the state of the >>>PeerConnection as it was with any previous answer removed. However, >>>I'm concerned about how this will interact with the ICE, etc stuff. >>>Someone want to throw out a suggestion? Cullen, Justin - how >>>*should*/*could* forking work within JSEP? >>> >>> >>>Aside on uses of forking: >>>I can see some additional interesting uses for parallel forking, >>>especially in non-phone-like usecases (games among others). The >>>server (or another participant) could hold open an OFFER in order to >>>forward it to any potential new partners. This might apply to a >>>conference call as well if there's a peer-2-peer aspect (mesh, >>>partial-mesh, etc) >>to it. >>> >>>Think in a game or 2nd-life-type-sim, where you're automatically in a >>>voice chat with anyone within hearing range, and those voice chats >>>are done p2p by forking each player's original offer to the server, >>>and forwarding it (forking it) to the new user, who would answer and >>>they'd be in a call. >>> >>>If you wanted to get really fancy, you could even do some of the >>>negotiation in the server and rephrase each offer as an answer to the >>>other side, leading to a 1/2-RTT-to-the-server setup time (more-or- >>less: >>> >>>player 1 server player 2 >>>------------------------------------------------------------ >>>| | | >>>|--> Offer 1 ---------------->| | >>>| |<---------- Offer 2 <----| >>>| | | >>>... >>> Server decides they should talk >>>| | | >>>|<-- Answer(Offer 2) <--------|-----> Answer(Offer 1)-->| >>>|<------------------------- media --------------------->| >>> >>>Even if this is initiated by a player, there are equivalent graphs >>>that use 1/2 RTT (through the server to other player) to set up >channels. >>> >>>I should note however that ICE overhead may well swamp this fancy >>>setup and it may be over-reaching, but each 1/2 RTT removed is >>>significant, so there may be uses. >>> >>>> _____________ >>>> Roman Shpount >>>> >>>> >>>> On Mon, Feb 20, 2012 at 3:14 PM, Christer Holmberg >>>> >>> > >>>> wrote: >>>> >>>> >>>> Hi, >>>> >>>> Just to clarify: the new offer is for the same "session" as the >>>> previous offer, and is supposed to replace the previous offer. >>>> >>>> The browser can of course send a just-audio offer somewhere, >>>> and >>a >>>> just-video offer somewhere else, but would those even be >>>associated >>>> with the same PeerConnection? I thought we wanted only one >>>> offer/answer, which is the reason it has been suggested e.g. >>>> not >>>to >>>> support paralell forking in the browser. >>>> >>>> Regards, >>>> >>>> Christer >>>> ________________________________________ >>>> From: I=F1aki Baz Castillo [ibc@aliax.net ] >>>> Sent: Monday, February 20, 2012 10:13 PM >>>> To: Christer Holmberg >>>> Cc: Justin Uberti; rtcweb@ietf.org ; >>>> public-webrtc@w3.org >>>> Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous >>>> offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case] >>>> >>>> 2012/2/20 Christer Holmberg >>> >: >>>> > Q1. When the JS app requests the new offer (o-2), I assume >all >>>> resources etc associated with o-1 will be released (unless they >>>are >>>> also needed for o-2, that is). >>>> >>>> Does it mean that the browser is just capable of having *one* >>>> multimedia session at the same time? Well, in SIP world this >>>typically >>>> means putting on-hold the previous call so, indeed, resources >>>would be >>>> released. >>>> >>>> But, why couldn't the browser send a just-audio offer somewhere >>>and a >>>> just-video offer to other destination at the same time? >>>> >>>> -- >>>> I=F1aki Baz Castillo >>>> > >>>> _______________________________________________ >>>> 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 >>> >>> >>>-- >>>Randell Jesup >>>randell-ietf@jesup.org >>>_______________________________________________ >>>rtcweb mailing list >>>rtcweb@ietf.org >>>https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From pravindran@sonusnet.com Wed Feb 22 03:54: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 3EB5A21F861F for ; Wed, 22 Feb 2012 03:54:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.232 X-Spam-Level: X-Spam-Status: No, score=-2.232 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, J_CHICKENPOX_65=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 ZbeLBMuLcQR2 for ; Wed, 22 Feb 2012 03:54:26 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id F1DD221F86A7 for ; Wed, 22 Feb 2012 03:54:25 -0800 (PST) Received: from sonusmail05.sonusnet.com (sonusmail05.sonusnet.com [10.128.32.155]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q1MBt8nP009775; Wed, 22 Feb 2012 06:55:08 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Feb 2012 06:54:09 -0500 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Feb 2012 17:24:23 +0530 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, 22 Feb 2012 17:24:22 +0530 From: "Ravindran, Parthasarathi" To: Christer Holmberg , "Ejzak, Richard P (Richard)" , "rtcweb@ietf.org" , "public-webrtc@w3.org" Thread-Topic: [rtcweb] JSEP-02: New offer and answer to previous offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case] Thread-Index: AQHM8AqE+28vByK84kKxG08H/gll95ZF3BIAgAAASYCAAASXgIAAGTuAgADuMECAAH0N0IAAZRbggAAhZzCAAFDIgIAAkYmAgAABzOA= Date: Wed, 22 Feb 2012 11:54:22 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E041555@inba-mail01.sonusnet.com> References: <7F2072F1E0DE894DA4B517B93C6A05852C3D31BA37@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C3D31BA3A@ESESSCMS0356.eemea.ericsson.se> <4F42C2C7.3060802@jesup.org> <387F9047F55E8C42850AD6B3A7A03C6C0E040FFE@inba-mail01.sonusnet.com> <6F428EFD2B8C2F49A2FB1317291A76C11355D49C4E@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <387F9047F55E8C42850AD6B3A7A03C6C0E0412EB@inba-mail01.sonusnet.com> <6F428EFD2B8C2F49A2FB1317291A76C11355D4A115@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <387F9047F55E8C42850AD6B3A7A03C6C0E041386@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C3D915AAA@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3D915AAA@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 22 Feb 2012 11:54:23.0471 (UTC) FILETIME=[B8151FF0:01CCF158] Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case] 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, 22 Feb 2012 11:54:28 -0000 Hi Christer, I guess that we are talking the same in the different words. My intention i= s not to support parallel forking in browser (no RTP mixing and no cloning = of peerconnection) but supporting SIP parallel forking callflows using JSEP= multiple answer mechanism. So, any new answer in parallel forking will rep= lace the previous one in the browser and only one active media stream is po= ssible. Please let me where we are differing in this discussion. Thanks Partha >-----Original Message----- >From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >Sent: Wednesday, February 22, 2012 5:16 PM >To: Ravindran, Parthasarathi; Ejzak, Richard P (Richard); >rtcweb@ietf.org; public-webrtc@w3.org >Subject: RE: [rtcweb] JSEP-02: New offer and answer to previous offer >[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] > > >Hi, > >Just to clarify: my suggestion has been to support only serial forking >for a given PeerConnection, and for that PeerConnection any new answer >would replace the previous one. > >If paralell forking in the browser really is needed, one option is to >"clone" the PeerConnection. > >Regards, > >Christer > > > > >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of Ravindran, Parthasarathi >Sent: 22. helmikuuta 2012 5:32 >To: Ejzak, Richard P (Richard); rtcweb@ietf.org; public-webrtc@w3.org >Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous offer >[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] > >Hi Richard, > >Thanks for your comments. I have put the focus on the offer/answer >exchange between OffererJS and OffererUA in the callflow and assumed 18x >as reliable. I'm bit afraid to write too much details about SIP in this >forum (see RTCWeb archive for more details) :-) > >I'll update the callflow with PRACK & 200. Out of the 3 requested >usecases, I have provided 1 and 3 with this assumption. I'll send 2nd >usecase of serial forking with UPDATE and updated standard callflow for >1st & 3rd usecase ASAP. > >My intention is not to violate standard but I have provided the deployed >(real-time) usecases as Cullen requested and also mentioned in the same >mail how to make those callflow standard compliance. For your concern on >signaling standard deviation discussion within WebRTC, I'll write the >separate mail. > >Thanks >Partha > >>-----Original Message----- >>From: Ejzak, Richard P (Richard) [mailto:richard.ejzak@alcatel- >>lucent.com] >>Sent: Wednesday, February 22, 2012 4:15 AM >>To: Ravindran, Parthasarathi; rtcweb@ietf.org; public-webrtc@w3.org >>Subject: RE: [rtcweb] JSEP-02: New offer and answer to previous offer >>[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] >> >>Hi Partha, >>Thanks for the call flows and explanations. >> >>For all of your flows, it would really help if any deviation from RFC >>3261 or RFC 3264 is clearly noted in your flows. Further, it would >>help to be clear when you assume reliable or unreliable provisionals, >>since that makes a big difference. You appear to usually assume >>reliable provisionals, but I want to be sure. >> >>It would also help to identify the purpose of some key operations in >>each flow when not strictly for protocol conformance. For example, >>setting some flows to "inactive" is used to avoid having multiple media >>flows when parallel forking, but this is an application choice rather >>than a protocol necessity. >> >>You state that your earlier flow violates RFC 3261, and in an earlier >>posting you insist that it should be supported because some >>implementations behave that way. I have a real problem with this. >>Standards are meant to help in avoiding exactly this kind of situation >>and I don't think that non-standard behavior should be condoned by >>rtcweb. If there is good reason to support this kind of flow then it >>should be brought to the appropriate working group for consideration >>(not rtcweb). An endpoint could achieve similar behavior by mimicking >>standard serial forking procedures (which is what I thought you >>intended but you forgot to include the interim final responses or >>byes). Why not just use a sequence of UPDATEs and avoid these hassles? >> >>The three use cases I had in mind were: >> >>1) mimicking standard serial forking from a single endpoint to realize >>the equivalent of multiple ANSWERs to a single OFFER (although separate >>OFFER/ANSWER transactions using UPDATE would be cleaner) >>2) standard serial forking (with optional UPDATEs) >>3) standard parallel forking (with optional UPDATEs) >> >>Do we really need anything other than 2) and 3)? >> >>Richard >> >>-----Original Message----- >>From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] >>Sent: Tuesday, February 21, 2012 2:51 PM >>To: Ejzak, Richard P (Richard); rtcweb@ietf.org; public-webrtc@w3.org; >>Randell Jesup >>Subject: RE: [rtcweb] JSEP-02: New offer and answer to previous offer >>[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] >> >>Hi all, >> >>Till now, I'm writing the callflow with the assumption of browser as >>RTP Endpoint. Two JSEP example call flow are attached: >> >> 1) Two 180 with SDP (answer) and second 180's dialog comes up >>with 2xx with SDP >> 2) Two 180 with SDP (answer) and first 180's dialog comes up with >>2xx with SDP >> >>The above callflows are not the only way to solve the problem but it is >>one of the way to solve this callflow. The intention of these callflows >>are to indicate that multiple answers support in JSEP facilities for >>designing SIP parallel forking kind of services. The exact intention >>is as per >>http://www.ietf.org/mail-archive/web/rtcweb/current/msg03455.html >>and as follows: >> >>1) allow a setRemoteDesc(SDP_ANSWER) to follow a >>setRemoteDesc(SDP_ANSWER) >>2) document that in this case (multiple 2xx), the JS is responsible for >>sending BYE to the previous answerer. >> >>Please let me know your comments on the callflow. >> >>Hi Richard, >> >>Thanks for your clarification in the below mail. Please read inline for >>more comments >> >>Thanks >>Partha >> >>>-----Original Message----- >>>From: Ejzak, Richard P (Richard) [mailto:richard.ejzak@alcatel- >>>lucent.com] >>>Sent: Tuesday, February 21, 2012 8:05 PM >>>To: Ravindran, Parthasarathi; rtcweb@ietf.org; public-webrtc@w3.org >>>Subject: RE: [rtcweb] JSEP-02: New offer and answer to previous offer >>>[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] >>> >>>Hi Partha, >>>Regarding my earlier email (this earlier email was not distributed on >>>the webrtc list), I do not dispute that forking must be supported by >>>all SIP endpoints. Let me rephrase my earlier questions in light of >>>your latest call flow. >>> >>>Looking at your call flow, I see that you treat the case of multiple >>>answers from the same endpoint as a serial forking case (or do I >>>misunderstand your intent?). >> >> I agree that this callflow is allowed in JSEP and it is a >>violation of RFC 3261 and not RFC 3264. I explained in detail why this >>callflow shall be allowed in http://www.ietf.org/mail- >>archive/web/rtcweb/current/msg03478.html >> >> How do you determine that this is a >>>special type of serial forking and not a parallel forking case? >> >> I won't determine it. I will just update based on the last >>active answer. >> >> We have >>>at least three use cases for multiple ANSWER and it would be helpful >>>to see how they can be handled and distinguished in SIP signaling. >>> >> Please mentioned the three of them. I'll provide the callflow >>for the same >> >>>Also, PRANSWER as currently defined seems to have no analog in SIP. >>>Is this also your understanding? >> We have the common understanding here. I'm requesting to >>remove PR_ANSWER state as it complicates JS Offer/Answer FSM still more >(See: >>http://www.ietf.org/mail-archive/web/rtcweb/current/msg03489.html). >> >> >>> >>>I don't understand your statement that "It is possible to implement >>>parallel forking by keeping only one answer active in the offerer side >>>at the given time". It would appear that an implementation of >>>parallel forking would need to keep the last answer from each dialog >active. >>>Please explain. >>> >> Hope the callflow clarifies >> >>>I look forward to your next call flow. >>> >>>Richard >>> >>>-----Original Message----- >>>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >>>Behalf Of Ravindran, Parthasarathi >>>Sent: Tuesday, February 21, 2012 12:58 AM >>>To: Randell Jesup; rtcweb@ietf.org; public-webrtc@w3.org >>>Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous offer >>>[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] >>> >>>Randell, >>> >>>It is possible to implement parallel forking by keeping only one >>>answer active in the offerer side at the given time. I attached one of >>>the example "18x with SDP and 2xx with different SDP" for your >>>reference which will map to serial forking. Please let me know your >>>concern about ICE interaction concern here. >>> >>>I'll send multiple 18x with SDP and one 2xx with SDP response JSEP >>>example using UPDATE O/A mechanism ASAP for clarity on parallel >>>forking >>>(assumption: multiple answer for single offer is supported in JSEP). >>> >>>Thanks >>>Partha >>> >>>>-----Original Message----- >>>>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >>>>Behalf Of Randell Jesup >>>>Sent: Tuesday, February 21, 2012 3:32 AM >>>>To: rtcweb@ietf.org; public-webrtc@w3.org >>>>Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous offer >>>>[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] >>>> >>>>On 2/20/2012 3:31 PM, Roman Shpount wrote: >>>>> Not to beat this horse to death, but why is it "suggested not to >>>>> have parallel forking"? WebRTC intorduces additional restrictions >>>>> on RTP stream (remote media sources and SSRCs are known in advance) >>>>> that make parallel forking implementation trivial. Only thing that >>>>> is missing is some way to clone the PeerConnection in the API. >>>> >>>>Right; parallel forking has uses. >>>> >>>>We've talked about this, but not for a while. One way to implement >>>>it would be to on each forked answer clone the state of the >>>>PeerConnection as it was with any previous answer removed. However, >>>>I'm concerned about how this will interact with the ICE, etc stuff. >>>>Someone want to throw out a suggestion? Cullen, Justin - how >>>>*should*/*could* forking work within JSEP? >>>> >>>> >>>>Aside on uses of forking: >>>>I can see some additional interesting uses for parallel forking, >>>>especially in non-phone-like usecases (games among others). The >>>>server (or another participant) could hold open an OFFER in order to >>>>forward it to any potential new partners. This might apply to a >>>>conference call as well if there's a peer-2-peer aspect (mesh, >>>>partial-mesh, etc) >>>to it. >>>> >>>>Think in a game or 2nd-life-type-sim, where you're automatically in a >>>>voice chat with anyone within hearing range, and those voice chats >>>>are done p2p by forking each player's original offer to the server, >>>>and forwarding it (forking it) to the new user, who would answer and >>>>they'd be in a call. >>>> >>>>If you wanted to get really fancy, you could even do some of the >>>>negotiation in the server and rephrase each offer as an answer to the >>>>other side, leading to a 1/2-RTT-to-the-server setup time (more-or- >>>less: >>>> >>>>player 1 server player 2 >>>>------------------------------------------------------------ >>>>| | | >>>>|--> Offer 1 ---------------->| | >>>>| |<---------- Offer 2 <----| >>>>| | | >>>>... >>>> Server decides they should talk >>>>| | | >>>>|<-- Answer(Offer 2) <--------|-----> Answer(Offer 1)-->| >>>>|<------------------------- media --------------------->| >>>> >>>>Even if this is initiated by a player, there are equivalent graphs >>>>that use 1/2 RTT (through the server to other player) to set up >>channels. >>>> >>>>I should note however that ICE overhead may well swamp this fancy >>>>setup and it may be over-reaching, but each 1/2 RTT removed is >>>>significant, so there may be uses. >>>> >>>>> _____________ >>>>> Roman Shpount >>>>> >>>>> >>>>> On Mon, Feb 20, 2012 at 3:14 PM, Christer Holmberg >>>>> >>>> > >>>>> wrote: >>>>> >>>>> >>>>> Hi, >>>>> >>>>> Just to clarify: the new offer is for the same "session" as the >>>>> previous offer, and is supposed to replace the previous offer. >>>>> >>>>> The browser can of course send a just-audio offer somewhere, >>>>> and >>>a >>>>> just-video offer somewhere else, but would those even be >>>>associated >>>>> with the same PeerConnection? I thought we wanted only one >>>>> offer/answer, which is the reason it has been suggested e.g. >>>>> not >>>>to >>>>> support paralell forking in the browser. >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> ________________________________________ >>>>> From: I=F1aki Baz Castillo [ibc@aliax.net ] >>>>> Sent: Monday, February 20, 2012 10:13 PM >>>>> To: Christer Holmberg >>>>> Cc: Justin Uberti; rtcweb@ietf.org ; >>>>> public-webrtc@w3.org >>>>> Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous >>>>> offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case] >>>>> >>>>> 2012/2/20 Christer Holmberg >>>> >: >>>>> > Q1. When the JS app requests the new offer (o-2), I assume >>all >>>>> resources etc associated with o-1 will be released (unless they >>>>are >>>>> also needed for o-2, that is). >>>>> >>>>> Does it mean that the browser is just capable of having *one* >>>>> multimedia session at the same time? Well, in SIP world this >>>>typically >>>>> means putting on-hold the previous call so, indeed, resources >>>>would be >>>>> released. >>>>> >>>>> But, why couldn't the browser send a just-audio offer somewhere >>>>and a >>>>> just-video offer to other destination at the same time? >>>>> >>>>> -- >>>>> I=F1aki Baz Castillo >>>>> > >>>>> _______________________________________________ >>>>> 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 >>>> >>>> >>>>-- >>>>Randell Jesup >>>>randell-ietf@jesup.org >>>>_______________________________________________ >>>>rtcweb mailing list >>>>rtcweb@ietf.org >>>>https://www.ietf.org/mailman/listinfo/rtcweb >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From sohel_khan@cable.comcast.com Wed Feb 22 07:18: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 957BE21F87A3 for ; Wed, 22 Feb 2012 07:18:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=-1.768, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_65=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4GIdiSQAFt9p for ; Wed, 22 Feb 2012 07:18:35 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id AA33121F87A9 for ; Wed, 22 Feb 2012 07:18:35 -0800 (PST) Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.6919331; Wed, 22 Feb 2012 08:08:06 -0700 Received: from PACDCEXMB02.cable.comcast.com ([fe80::9803:aba4:1ac8:474e]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0355.002; Wed, 22 Feb 2012 10:18:31 -0500 From: "Khan, Sohel" To: "Ravindran, Parthasarathi" , "Ejzak, Richard P (Richard)" , "rtcweb@ietf.org" , "public-webrtc@w3.org" Thread-Topic: [rtcweb] JSEP-02: New offer and answer to previous offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case] Thread-Index: AQHM8VeSdAQ+3lvLgUSlguJuYl+aP5ZI8EAg Date: Wed, 22 Feb 2012 15:18:30 +0000 Deferred-Delivery: Wed, 22 Feb 2012 14:26:00 +0000 Message-ID: <837E772D16C77141BFA5FEC3F30487FF525CA77C@PACDCEXMB02.cable.comcast.com> References: <7F2072F1E0DE894DA4B517B93C6A05852C3D31BA37@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C3D31BA3A@ESESSCMS0356.eemea.ericsson.se> <4F42C2C7.3060802@jesup.org> <387F9047F55E8C42850AD6B3A7A03C6C0E040FFE@inba-mail01.sonusnet.com> <6F428EFD2B8C2F49A2FB1317291A76C11355D49C4E@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <387F9047F55E8C42850AD6B3A7A03C6C0E0412EB@inba-mail01.sonusnet.com> <6F428EFD2B8C2F49A2FB1317291A76C11355D4A115@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <387F9047F55E8C42850AD6B3A7A03C6C0E041386@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E041386@inba-mail01.sonusnet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.40.56.171] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case] 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, 22 Feb 2012 15:18:39 -0000 Partha, If possible, please minimize the use of PRACK in the call flow. We would li= ke to have call flows simple and less chatty. Sohel -----Original Message----- From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com]=20 Sent: Tuesday, February 21, 2012 10:32 PM To: Ejzak, Richard P (Richard); rtcweb@ietf.org; public-webrtc@w3.org Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous offer [was:= JSEP-02: SDP_PRANSWER and FEDEX use-case] Hi Richard, Thanks for your comments. I have put the focus on the offer/answer exchange= between OffererJS and OffererUA in the callflow and assumed 18x as reliabl= e. I'm bit afraid to write too much details about SIP in this forum (see RT= CWeb archive for more details) :-) I'll update the callflow with PRACK & 200. Out of the 3 requested usecases,= I have provided 1 and 3 with this assumption. I'll send 2nd usecase of ser= ial forking with UPDATE and updated standard callflow for 1st & 3rd usecase= ASAP. My intention is not to violate standard but I have provided the deployed (r= eal-time) usecases as Cullen requested and also mentioned in the same mail = how to make those callflow standard compliance. For your concern on signali= ng standard deviation discussion within WebRTC, I'll write the separate mai= l. Thanks Partha >-----Original Message----- >From: Ejzak, Richard P (Richard) [mailto:richard.ejzak@alcatel-=20 >lucent.com] >Sent: Wednesday, February 22, 2012 4:15 AM >To: Ravindran, Parthasarathi; rtcweb@ietf.org; public-webrtc@w3.org >Subject: RE: [rtcweb] JSEP-02: New offer and answer to previous offer >[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] > >Hi Partha, >Thanks for the call flows and explanations. > >For all of your flows, it would really help if any deviation from RFC >3261 or RFC 3264 is clearly noted in your flows. Further, it would=20 >help to be clear when you assume reliable or unreliable provisionals,=20 >since that makes a big difference. You appear to usually assume=20 >reliable provisionals, but I want to be sure. > >It would also help to identify the purpose of some key operations in=20 >each flow when not strictly for protocol conformance. For example,=20 >setting some flows to "inactive" is used to avoid having multiple media=20 >flows when parallel forking, but this is an application choice rather=20 >than a protocol necessity. > >You state that your earlier flow violates RFC 3261, and in an earlier=20 >posting you insist that it should be supported because some=20 >implementations behave that way. I have a real problem with this. >Standards are meant to help in avoiding exactly this kind of situation=20 >and I don't think that non-standard behavior should be condoned by=20 >rtcweb. If there is good reason to support this kind of flow then it=20 >should be brought to the appropriate working group for consideration=20 >(not rtcweb). An endpoint could achieve similar behavior by mimicking=20 >standard serial forking procedures (which is what I thought you=20 >intended but you forgot to include the interim final responses or=20 >byes). Why not just use a sequence of UPDATEs and avoid these hassles? > >The three use cases I had in mind were: > >1) mimicking standard serial forking from a single endpoint to realize=20 >the equivalent of multiple ANSWERs to a single OFFER (although separate=20 >OFFER/ANSWER transactions using UPDATE would be cleaner) >2) standard serial forking (with optional UPDATEs) >3) standard parallel forking (with optional UPDATEs) > >Do we really need anything other than 2) and 3)? > >Richard > >-----Original Message----- >From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] >Sent: Tuesday, February 21, 2012 2:51 PM >To: Ejzak, Richard P (Richard); rtcweb@ietf.org; public-webrtc@w3.org;=20 >Randell Jesup >Subject: RE: [rtcweb] JSEP-02: New offer and answer to previous offer >[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] > >Hi all, > >Till now, I'm writing the callflow with the assumption of browser as=20 >RTP Endpoint. Two JSEP example call flow are attached: > > 1) Two 180 with SDP (answer) and second 180's dialog comes up with 2xx=20 >with SDP > 2) Two 180 with SDP (answer) and first 180's dialog comes up with=20 >2xx with SDP > >The above callflows are not the only way to solve the problem but it is=20 >one of the way to solve this callflow. The intention of these callflows=20 >are to indicate that multiple answers support in JSEP facilities for=20 >designing SIP parallel forking kind of services. The exact intention=20 >is as per=20 >http://www.ietf.org/mail-archive/web/rtcweb/current/msg03455.html >and as follows: > >1) allow a setRemoteDesc(SDP_ANSWER) to follow a >setRemoteDesc(SDP_ANSWER) >2) document that in this case (multiple 2xx), the JS is responsible for=20 >sending BYE to the previous answerer. > >Please let me know your comments on the callflow. > >Hi Richard, > >Thanks for your clarification in the below mail. Please read inline for=20 >more comments > >Thanks >Partha > >>-----Original Message----- >>From: Ejzak, Richard P (Richard) [mailto:richard.ejzak@alcatel-=20 >>lucent.com] >>Sent: Tuesday, February 21, 2012 8:05 PM >>To: Ravindran, Parthasarathi; rtcweb@ietf.org; public-webrtc@w3.org >>Subject: RE: [rtcweb] JSEP-02: New offer and answer to previous offer >>[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] >> >>Hi Partha, >>Regarding my earlier email (this earlier email was not distributed on=20 >>the webrtc list), I do not dispute that forking must be supported by=20 >>all SIP endpoints. Let me rephrase my earlier questions in light of=20 >>your latest call flow. >> >>Looking at your call flow, I see that you treat the case of multiple=20 >>answers from the same endpoint as a serial forking case (or do I=20 >>misunderstand your intent?). > > I agree that this callflow is allowed in JSEP and it is a=20 >violation of RFC 3261 and not RFC 3264. I explained in detail why this=20 >callflow shall be allowed in http://www.ietf.org/mail-=20 >archive/web/rtcweb/current/msg03478.html > > How do you determine that this is a >>special type of serial forking and not a parallel forking case? > > I won't determine it. I will just update based on the last=20 >active answer. > > We have >>at least three use cases for multiple ANSWER and it would be helpful=20 >>to see how they can be handled and distinguished in SIP signaling. >> > Please mentioned the three of them. I'll provide the callflow=20 >for the same > >>Also, PRANSWER as currently defined seems to have no analog in SIP. =20 >>Is this also your understanding? > We have the common understanding here. I'm requesting to=20 >remove PR_ANSWER state as it complicates JS Offer/Answer FSM still more (S= ee: >http://www.ietf.org/mail-archive/web/rtcweb/current/msg03489.html). > > >> >>I don't understand your statement that "It is possible to implement=20 >>parallel forking by keeping only one answer active in the offerer side=20 >>at the given time". It would appear that an implementation of=20 >>parallel forking would need to keep the last answer from each dialog acti= ve. >>Please explain. >> > Hope the callflow clarifies > >>I look forward to your next call flow. >> >>Richard >> >>-----Original Message----- >>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On=20 >>Behalf Of Ravindran, Parthasarathi >>Sent: Tuesday, February 21, 2012 12:58 AM >>To: Randell Jesup; rtcweb@ietf.org; public-webrtc@w3.org >>Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous offer >>[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] >> >>Randell, >> >>It is possible to implement parallel forking by keeping only one=20 >>answer active in the offerer side at the given time. I attached one of=20 >>the example "18x with SDP and 2xx with different SDP" for your=20 >>reference which will map to serial forking. Please let me know your=20 >>concern about ICE interaction concern here. >> >>I'll send multiple 18x with SDP and one 2xx with SDP response JSEP=20 >>example using UPDATE O/A mechanism ASAP for clarity on parallel=20 >>forking >>(assumption: multiple answer for single offer is supported in JSEP). >> >>Thanks >>Partha >> >>>-----Original Message----- >>>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On=20 >>>Behalf Of Randell Jesup >>>Sent: Tuesday, February 21, 2012 3:32 AM >>>To: rtcweb@ietf.org; public-webrtc@w3.org >>>Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous offer >>>[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] >>> >>>On 2/20/2012 3:31 PM, Roman Shpount wrote: >>>> Not to beat this horse to death, but why is it "suggested not to=20 >>>> have parallel forking"? WebRTC intorduces additional restrictions=20 >>>> on RTP stream (remote media sources and SSRCs are known in advance)=20 >>>> that make parallel forking implementation trivial. Only thing that=20 >>>> is missing is some way to clone the PeerConnection in the API. >>> >>>Right; parallel forking has uses. >>> >>>We've talked about this, but not for a while. One way to implement=20 >>>it would be to on each forked answer clone the state of the=20 >>>PeerConnection as it was with any previous answer removed. However,=20 >>>I'm concerned about how this will interact with the ICE, etc stuff. >>>Someone want to throw out a suggestion? Cullen, Justin - how >>>*should*/*could* forking work within JSEP? >>> >>> >>>Aside on uses of forking: >>>I can see some additional interesting uses for parallel forking,=20 >>>especially in non-phone-like usecases (games among others). The=20 >>>server (or another participant) could hold open an OFFER in order to=20 >>>forward it to any potential new partners. This might apply to a=20 >>>conference call as well if there's a peer-2-peer aspect (mesh,=20 >>>partial-mesh, etc) >>to it. >>> >>>Think in a game or 2nd-life-type-sim, where you're automatically in a=20 >>>voice chat with anyone within hearing range, and those voice chats=20 >>>are done p2p by forking each player's original offer to the server,=20 >>>and forwarding it (forking it) to the new user, who would answer and=20 >>>they'd be in a call. >>> >>>If you wanted to get really fancy, you could even do some of the=20 >>>negotiation in the server and rephrase each offer as an answer to the=20 >>>other side, leading to a 1/2-RTT-to-the-server setup time (more-or- >>less: >>> >>>player 1 server player 2 >>>------------------------------------------------------------ >>>| | | >>>|--> Offer 1 ---------------->| | >>>| |<---------- Offer 2 <----| >>>| | | >>>... >>> Server decides they should talk >>>| | | >>>|<-- Answer(Offer 2) <--------|-----> Answer(Offer 1)-->| >>>|<------------------------- media --------------------->| >>> >>>Even if this is initiated by a player, there are equivalent graphs=20 >>>that use 1/2 RTT (through the server to other player) to set up >channels. >>> >>>I should note however that ICE overhead may well swamp this fancy=20 >>>setup and it may be over-reaching, but each 1/2 RTT removed is=20 >>>significant, so there may be uses. >>> >>>> _____________ >>>> Roman Shpount >>>> >>>> >>>> On Mon, Feb 20, 2012 at 3:14 PM, Christer Holmberg=20 >>>> >>> > >>>> wrote: >>>> >>>> >>>> Hi, >>>> >>>> Just to clarify: the new offer is for the same "session" as the >>>> previous offer, and is supposed to replace the previous offer. >>>> >>>> The browser can of course send a just-audio offer somewhere,=20 >>>> and >>a >>>> just-video offer somewhere else, but would those even be >>>associated >>>> with the same PeerConnection? I thought we wanted only one >>>> offer/answer, which is the reason it has been suggested e.g.=20 >>>> not >>>to >>>> support paralell forking in the browser. >>>> >>>> Regards, >>>> >>>> Christer >>>> ________________________________________ >>>> From: I=F1aki Baz Castillo [ibc@aliax.net ] >>>> Sent: Monday, February 20, 2012 10:13 PM >>>> To: Christer Holmberg >>>> Cc: Justin Uberti; rtcweb@ietf.org ; >>>> public-webrtc@w3.org >>>> Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous >>>> offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case] >>>> >>>> 2012/2/20 Christer Holmberg >>> >: >>>> > Q1. When the JS app requests the new offer (o-2), I assume >all >>>> resources etc associated with o-1 will be released (unless they >>>are >>>> also needed for o-2, that is). >>>> >>>> Does it mean that the browser is just capable of having *one* >>>> multimedia session at the same time? Well, in SIP world this >>>typically >>>> means putting on-hold the previous call so, indeed, resources >>>would be >>>> released. >>>> >>>> But, why couldn't the browser send a just-audio offer somewhere >>>and a >>>> just-video offer to other destination at the same time? >>>> >>>> -- >>>> I=F1aki Baz Castillo >>>> > >>>> _______________________________________________ >>>> 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 >>> >>> >>>-- >>>Randell Jesup >>>randell-ietf@jesup.org >>>_______________________________________________ >>>rtcweb mailing list >>>rtcweb@ietf.org >>>https://www.ietf.org/mailman/listinfo/rtcweb From ted.ietf@gmail.com Thu Feb 23 08:28: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 3293621F874A for ; Thu, 23 Feb 2012 08:28:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.682 X-Spam-Level: X-Spam-Status: No, score=-3.682 tagged_above=-999 required=5 tests=[AWL=-0.083, 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 BK8V2dS5vqaT for ; Thu, 23 Feb 2012 08:28:21 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9B91721F8600 for ; Thu, 23 Feb 2012 08:28:21 -0800 (PST) Received: by vcbfk14 with SMTP id fk14so1076787vcb.31 for ; Thu, 23 Feb 2012 08:28:21 -0800 (PST) Received-SPF: pass (google.com: domain of ted.ietf@gmail.com designates 10.220.156.72 as permitted sender) client-ip=10.220.156.72; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ted.ietf@gmail.com designates 10.220.156.72 as permitted sender) smtp.mail=ted.ietf@gmail.com; dkim=pass header.i=ted.ietf@gmail.com Received: from mr.google.com ([10.220.156.72]) by 10.220.156.72 with SMTP id v8mr1422355vcw.45.1330014501200 (num_hops = 1); Thu, 23 Feb 2012 08:28:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=Lfk/bYb6Wb8skV5VX6u5YZHyaU9a0+fqYvm8X4gXAjY=; b=gyY9S+8959Aj/AkhlzEoMmfT1rW/DBigBIKtqW7ij9z2wQEXR1Q1VPN4WZRxOAvmVN fLaeTCr/0KEV98uHsuEZejVfQEQtFISc59wT6zq/xrAKvPGraoQSab4bniSse+RghnPv nWWluB470AVYD21S5qlpeDfUTpPhszn46e5O4= MIME-Version: 1.0 Received: by 10.220.156.72 with SMTP id v8mr1178050vcw.45.1330014501162; Thu, 23 Feb 2012 08:28:21 -0800 (PST) Received: by 10.52.31.68 with HTTP; Thu, 23 Feb 2012 08:28:21 -0800 (PST) Date: Thu, 23 Feb 2012 08:28:21 -0800 Message-ID: From: Ted Hardie To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [rtcweb] Working group draft consensus call for 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, 23 Feb 2012 16:28:22 -0000 The chairs have reviewed the discussion during the interim meeting and the subsequent discussion on the mailing list, and we believe that there is rough consensus to make JSEP the input document for further work in this area. We ask the document authors to submit a working group draft -00 for the next version of the document. regards, Ted Hardie From christer.holmberg@ericsson.com Thu Feb 23 23:10:08 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 D428D21E800C for ; Thu, 23 Feb 2012 23:10:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.113 X-Spam-Level: X-Spam-Status: No, score=-10.113 tagged_above=-999 required=5 tests=[AWL=0.486, 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 wD25BKv7ZOvD for ; Thu, 23 Feb 2012 23:10:06 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 64B8F21F86B6 for ; Thu, 23 Feb 2012 23:10:03 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-36-4f4737ca4222 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id C2.73.01970.AC7374F4; Fri, 24 Feb 2012 08:10:02 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Fri, 24 Feb 2012 08:10:02 +0100 From: Christer Holmberg To: "rtcweb@ietf.org" Date: Fri, 24 Feb 2012 08:09:59 +0100 Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-00.txt Thread-Index: AczywlP2evfTkWzBSNiYTWIDPD9D5AAAOHcQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3D9614CC@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-Brightmail-Tracker: AAAAAA== Subject: [rtcweb] FW: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-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: Fri, 24 Feb 2012 07:10:08 -0000 =20 FYI, A milestone for BUNDLE has been created in MMUSIC, and the first draft-ietf= version of the draft has been submitted. Regards, Christer -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= internet-drafts@ietf.org Sent: 24. helmikuuta 2012 9:02 To: i-d-announce@ietf.org Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-00.t= xt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control= Working Group of the IETF. Title : Multiplexing Negotiation Using Session Description Proto= col (SDP) Port Numbers Author(s) : Christer Holmberg Harald Tveit Alvestrand Filename : draft-ietf-mmusic-sdp-bundle-negotiation-00.txt Pages : 11 Date : 2012-02-23 This specification defines a new SDP Grouping Framework SDP grouping framework extension, "BUNDLE", that can be used with the Session Description Protocol (SDP) Offer/Answer mechanism to negotiate the usage of bundled media, which refers to the usage of a single 5-tuple for media associated with multiple SDP media descriptions ("m=3D" lines). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-bundle-negotiatio= n-00.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-ietf-mmusic-sdp-bundle-negotiation= -00.txt _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From magnus.westerlund@ericsson.com Fri Feb 24 01:35: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 A79F221F85D7 for ; Fri, 24 Feb 2012 01:35:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.242 X-Spam-Level: X-Spam-Status: No, score=-111.242 tagged_above=-999 required=5 tests=[AWL=1.357, BAYES_00=-2.599, GB_I_INVITATION=-2, 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 HgGmp9yWAsKT for ; Fri, 24 Feb 2012 01:35:37 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 6D8E721F85D1 for ; Fri, 24 Feb 2012 01:35:37 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-4a-4f4759e894c9 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 04.E9.27041.8E9574F4; Fri, 24 Feb 2012 10:35:36 +0100 (CET) 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; Fri, 24 Feb 2012 10:35:35 +0100 Message-ID: <4F4759DC.7060303@ericsson.com> Date: Fri, 24 Feb 2012 10:35:24 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [rtcweb] Resolving RTP/SDES question in Paris 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, 24 Feb 2012 09:35:38 -0000 WG, There has been extensive discussion at WG meetings at whether we need to support SDES and RTP in addition to DTLS-SRTP. The architecture draft currently has a giant "Open Issue" text around the question of the appropriate level of support for modes less secure that DTLS-SRTP. The draft currently implicitly allows but does not require these modes: Implementations MUST implement DTLS and DTLS-SRTP. All data channels MUST be secured via DTLS. DTLS-SRTP MUST be offered for every media channel and MUST be the default; i.e., if an implementation receives an offer for DTLS-SRTP and SDES and/or plain RTP, DTLS-SRTP MUST be selected. The chairs intend to use significant meeting time in Paris with an aim to reach consensus around this issue. Please consider this thread an invitation to discuss this topic on the list. In Paris, we intend to have a presentation summarizing the discussion so far, digging into the details of different possible outcomes and of the arguments have been raised in order to set the stage for a discussion and a consensus call. Please come prepared to have that discussion in Paris. Magnus Westerlund (For the WG chairs) ---------------------------------------------------------------------- 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 xavier.marjou@gmail.com Fri Feb 24 06:46: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 3B79021F842C; Fri, 24 Feb 2012 06:46:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 9tjxZGXuIGPV; Fri, 24 Feb 2012 06:46:29 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2916521F8429; Fri, 24 Feb 2012 06:46:29 -0800 (PST) Received: by obbwd15 with SMTP id wd15so3396346obb.31 for ; Fri, 24 Feb 2012 06:46:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Z0zAvedrRPL1QmFm9KJXcKQyDsDMpSCzkru69Pbu6PM=; b=tKKWIuQL+b4hKrVHwpL60Y+mahmQzWj/VXhjPmWzPGz1vtApu/twbed8XUTwuHNwiF RzEGiKN+ZUhUIKDK3MyKPbIEKEnbXQyoFzEsfXs9lCHiXYgneyw3h4qlGPmPd6ByTID2 qCegJOupTdyTbIO9l5OliPVglSocfC4WEQuhU= MIME-Version: 1.0 Received: by 10.60.28.168 with SMTP id c8mr805242oeh.35.1330094788697; Fri, 24 Feb 2012 06:46:28 -0800 (PST) Sender: xavier.marjou@gmail.com Received: by 10.60.2.70 with HTTP; Fri, 24 Feb 2012 06:46:28 -0800 (PST) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3D9614CC@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C3D9614CC@ESESSCMS0356.eemea.ericsson.se> Date: Fri, 24 Feb 2012 15:46:28 +0100 X-Google-Sender-Auth: KOY1rSE5q5_4ZzDc59XY1yPP6ec Message-ID: From: Xavier Marjou To: Christer Holmberg Content-Type: multipart/alternative; boundary=e89a8ff1c4e865e01504b9b6d3d4 Cc: rtcweb@ietf.org, IETF MMUSIC WG Subject: Re: [rtcweb] FW: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-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: Fri, 24 Feb 2012 14:46:30 -0000 --e89a8ff1c4e865e01504b9b6d3d4 Content-Type: text/plain; charset=ISO-8859-1 A minor remark regarding the examples : ports 10000 and 20000 may already be busy. http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt Cheers, Xavier On Fri, Feb 24, 2012 at 8:09 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > > FYI, > > A milestone for BUNDLE has been created in MMUSIC, and the first > draft-ietf version of the draft has been submitted. > > Regards, > > Christer > > > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf > Of internet-drafts@ietf.org > Sent: 24. helmikuuta 2012 9:02 > To: i-d-announce@ietf.org > Cc: mmusic@ietf.org > Subject: [MMUSIC] I-D Action: > draft-ietf-mmusic-sdp-bundle-negotiation-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Multiparty Multimedia Session > Control Working Group of the IETF. > > Title : Multiplexing Negotiation Using Session > Description Protocol (SDP) Port Numbers > Author(s) : Christer Holmberg > Harald Tveit Alvestrand > Filename : draft-ietf-mmusic-sdp-bundle-negotiation-00.txt > Pages : 11 > Date : 2012-02-23 > > This specification defines a new SDP Grouping Framework SDP grouping > framework extension, "BUNDLE", that can be used with the Session > Description Protocol (SDP) Offer/Answer mechanism to negotiate the > usage of bundled media, which refers to the usage of a single 5-tuple > for media associated with multiple SDP media descriptions ("m=" > lines). > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-bundle-negotiation-00.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-ietf-mmusic-sdp-bundle-negotiation-00.txt > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --e89a8ff1c4e865e01504b9b6d3d4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable A minor remark regarding the examples : ports 10000 and 20000 may already b= e busy.
http://www.iana.org= /assignments/service-names-port-numbers/service-names-port-numbers.txt<= br>
Cheers,
Xavier

On Fri, Feb 24, 201= 2 at 8:09 AM, Christer Holmberg <christer.holmberg@ericsson.c= om> wrote:

FYI,

A milestone for BUNDLE has been created in MMUSIC, and the first draft-ietf= version of the draft has been submitted.

Regards,

Christer


-----Original Message-----
From: mmusic-b= ounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org
Sent: 24. helmikuuta 2012 9:02
To: i-d-announce= @ietf.org
Cc: mmusic@ietf.org
Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-00.t= xt


A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control= Working Group of the IETF.

=A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Multiplexing Negotiation Using = Session Description Protocol (SDP) Port Numbers
=A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Christer Holmberg
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Harald Tveit Alvestrand=
=A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-mmusic-sdp-bundle-nego= tiation-00.txt
=A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 11
=A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-02-23

=A0 This specification defines a new SDP Grouping Framework SDP grouping =A0 framework extension, "BUNDLE", that can be used with the Ses= sion
=A0 Description Protocol (SDP) Offer/Answer mechanism to negotiate the
=A0 usage of bundled media, which refers to the usage of a single 5-tuple<= br> =A0 for media associated with multiple SDP media descriptions ("m=3D&= quot;
=A0 lines).


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/= draft-ietf-mmusic-sdp-bundle-negotiation-00.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/dr= aft-ietf-mmusic-sdp-bundle-negotiation-00.txt

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

--e89a8ff1c4e865e01504b9b6d3d4-- From alan.b.johnston@gmail.com Fri Feb 24 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 473CD21F87B0; Fri, 24 Feb 2012 08:01:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.547 X-Spam-Level: X-Spam-Status: No, score=-103.547 tagged_above=-999 required=5 tests=[AWL=0.052, 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 EGl75foZ844r; Fri, 24 Feb 2012 08:01:51 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7D11E21F87AF; Fri, 24 Feb 2012 08:01:51 -0800 (PST) Received: by obbwd15 with SMTP id wd15so3485806obb.31 for ; Fri, 24 Feb 2012 08:01:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Os8VMX+NbJ12rZwTD/eXl/199RMSLy7zOnXimyeNJos=; b=x1TjMpQh7n2jsJIU9VTBhsfDMvGssMfwwsaKCovRg2/BoEcGQ8FUZWmHVZ7PwSY0RY MU/ctTjMnH3Z5EG3mYZ4oX7KPwZj3xpf8kX5lRyOgTo+P+fbN6ZEHfsX/cEnlwXDMJQd QDdIleJIQMlhvWkj6eEAVf6gVU94k2E60kj0w= MIME-Version: 1.0 Received: by 10.182.72.69 with SMTP id b5mr883461obv.77.1330099311103; Fri, 24 Feb 2012 08:01:51 -0800 (PST) Received: by 10.182.39.161 with HTTP; Fri, 24 Feb 2012 08:01:51 -0800 (PST) In-Reply-To: References: <7F2072F1E0DE894DA4B517B93C6A05852C3D9614CC@ESESSCMS0356.eemea.ericsson.se> Date: Fri, 24 Feb 2012 10:01:51 -0600 Message-ID: From: Alan Johnston To: Xavier Marjou Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org, IETF MMUSIC WG Subject: Re: [rtcweb] [MMUSIC] FW: I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-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: Fri, 24 Feb 2012 16:01:52 -0000 Also, there is no reference to RFC 5761 or use of a=3Drtcp-mux in the example. In Section 6.1 there is a typo 'rtpc-mux' - Alan - On Fri, Feb 24, 2012 at 8:46 AM, Xavier Marjou w= rote: > A minor remark regarding the examples : ports 10000 and 20000 may already= be > busy. > http://www.iana.org/assignments/service-names-port-numbers/service-names-= port-numbers.txt > > Cheers, > Xavier > > On Fri, Feb 24, 2012 at 8:09 AM, Christer Holmberg > wrote: >> >> >> FYI, >> >> A milestone for BUNDLE has been created in MMUSIC, and the first >> draft-ietf version of the draft has been submitted. >> >> Regards, >> >> Christer >> >> >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf >> Of internet-drafts@ietf.org >> Sent: 24. helmikuuta 2012 9:02 >> To: i-d-announce@ietf.org >> Cc: mmusic@ietf.org >> Subject: [MMUSIC] I-D Action: >> draft-ietf-mmusic-sdp-bundle-negotiation-00.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the Multiparty Multimedia Sess= ion >> Control Working Group of the IETF. >> >> =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Multiplexing Negotiation Usin= g Session >> Description Protocol (SDP) Port Numbers >> =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Christer Holmberg >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Harald Tveit Alvestra= nd >> =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-mmusic-sdp-bundle-ne= gotiation-00.txt >> =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 11 >> =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-02-23 >> >> =A0 This specification defines a new SDP Grouping Framework SDP grouping >> =A0 framework extension, "BUNDLE", that can be used with the Session >> =A0 Description Protocol (SDP) Offer/Answer mechanism to negotiate the >> =A0 usage of bundled media, which refers to the usage of a single 5-tupl= e >> =A0 for media associated with multiple SDP media descriptions ("m=3D" >> =A0 lines). >> >> >> A URL for this Internet-Draft is: >> >> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-bundle-negotia= tion-00.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-ietf-mmusic-sdp-bundle-negotiat= ion-00.txt >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From fluffy@iii.ca Fri Feb 24 08:05: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 28C2A21F8835 for ; Fri, 24 Feb 2012 08:05:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.296 X-Spam-Level: X-Spam-Status: No, score=-3.296 tagged_above=-999 required=5 tests=[AWL=0.303, 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 x+4FFYzjeCZ4 for ; Fri, 24 Feb 2012 08:05:31 -0800 (PST) Received: from fallback-in2.mxes.net (fallback-out2.mxes.net [216.86.168.191]) by ietfa.amsl.com (Postfix) with ESMTP id A092C21F881A for ; Fri, 24 Feb 2012 08:05:31 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by fallback-in1.mxes.net (Postfix) with ESMTP id F13BB2FD7C0 for ; Fri, 24 Feb 2012 11:05:24 -0500 (EST) 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 6FAEC22E25C for ; Fri, 24 Feb 2012 11:05:24 -0500 (EST) From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 24 Feb 2012 09:05:24 -0700 References: <20120223202723.7684.62927.idtracker@ietfa.amsl.com> To: rtcweb@ietf.org Message-Id: <8D2D74DE-DCA2-4CA9-AEAF-A466B9617562@iii.ca> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [rtcweb] Fwd: rtcweb - Requested sessions have been scheduled for IETF 83 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, 24 Feb 2012 16:05:32 -0000 FYI on meeting time at IETF 83 - note this is *draft* and may change. Begin forwarded message: > rtcweb Session 1 (2.5 hours) > Wednesday, Morning Session I 0930-1130 > Room Name: 252B > --------------------------------------------- > rtcweb Session 2 (2.5 hours) > Thursday, Morning Session I 0930-1130 > Room Name: Maillot > --------------------------------------------- From christer.holmberg@ericsson.com Sun Feb 26 00:00: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 307C821F8643; Sun, 26 Feb 2012 00:00:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.137 X-Spam-Level: X-Spam-Status: No, score=-10.137 tagged_above=-999 required=5 tests=[AWL=0.462, 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 zGdY+ULoB1ZU; Sun, 26 Feb 2012 00:00:40 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 38FAC21F863F; Sun, 26 Feb 2012 00:00:40 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-1a-4f49e6a6ff35 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id AB.9C.27041.6A6E94F4; Sun, 26 Feb 2012 09:00:38 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.31]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Sun, 26 Feb 2012 09:00:37 +0100 From: Christer Holmberg To: Alan Johnston , Xavier Marjou Date: Sun, 26 Feb 2012 08:59:15 +0100 Thread-Topic: [MMUSIC] [rtcweb] FW: I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-00.txt Thread-Index: AczzDZ9hCZQ11KUKROiPIv27tYrUTABTulFP Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3F48C5DC@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C3D9614CC@ESESSCMS0356.eemea.ericsson.se> , 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 X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" , IETF MMUSIC WG Subject: Re: [rtcweb] [MMUSIC] FW: I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-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: Sun, 26 Feb 2012 08:00:42 -0000 Hi Alan and Xavier, Thanks for your comments! Regards, Christer ________________________________________ From: Alan Johnston [alan.b.johnston@gmail.com] Sent: Friday, February 24, 2012 6:01 PM To: Xavier Marjou Cc: Christer Holmberg; rtcweb@ietf.org; IETF MMUSIC WG Subject: Re: [MMUSIC] [rtcweb] FW: I-D Action: draft-ietf-mmusic-sdp-bundle= -negotiation-00.txt Also, there is no reference to RFC 5761 or use of a=3Drtcp-mux in the example. In Section 6.1 there is a typo 'rtpc-mux' - Alan - On Fri, Feb 24, 2012 at 8:46 AM, Xavier Marjou w= rote: > A minor remark regarding the examples : ports 10000 and 20000 may already= be > busy. > http://www.iana.org/assignments/service-names-port-numbers/service-names-= port-numbers.txt > > Cheers, > Xavier > > On Fri, Feb 24, 2012 at 8:09 AM, Christer Holmberg > wrote: >> >> >> FYI, >> >> A milestone for BUNDLE has been created in MMUSIC, and the first >> draft-ietf version of the draft has been submitted. >> >> Regards, >> >> Christer >> >> >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf >> Of internet-drafts@ietf.org >> Sent: 24. helmikuuta 2012 9:02 >> To: i-d-announce@ietf.org >> Cc: mmusic@ietf.org >> Subject: [MMUSIC] I-D Action: >> draft-ietf-mmusic-sdp-bundle-negotiation-00.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the Multiparty Multimedia Sess= ion >> Control Working Group of the IETF. >> >> Title : Multiplexing Negotiation Using Session >> Description Protocol (SDP) Port Numbers >> Author(s) : Christer Holmberg >> Harald Tveit Alvestrand >> Filename : draft-ietf-mmusic-sdp-bundle-negotiation-00.txt >> Pages : 11 >> Date : 2012-02-23 >> >> This specification defines a new SDP Grouping Framework SDP grouping >> framework extension, "BUNDLE", that can be used with the Session >> Description Protocol (SDP) Offer/Answer mechanism to negotiate the >> usage of bundled media, which refers to the usage of a single 5-tuple >> for media associated with multiple SDP media descriptions ("m=3D" >> lines). >> >> >> A URL for this Internet-Draft is: >> >> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-bundle-negotia= tion-00.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-ietf-mmusic-sdp-bundle-negotiat= ion-00.txt >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From pravindran@sonusnet.com Sun Feb 26 18:15:08 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 E4A1221F84A5 for ; Sun, 26 Feb 2012 18:15:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[AWL=-1.413, BAYES_40=-0.185, J_CHICKENPOX_65=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 EyjyshfbiDLO for ; Sun, 26 Feb 2012 18:15:07 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 10B8821F849D for ; Sun, 26 Feb 2012 18:15:06 -0800 (PST) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q1R2FniI002263; Sun, 26 Feb 2012 21:15:49 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 26 Feb 2012 21:14:59 -0500 Received: from INBA-HUB02.sonusnet.com ([10.70.51.87]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 27 Feb 2012 07:44:56 +0530 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, 27 Feb 2012 07:44:56 +0530 From: "Ravindran, Parthasarathi" To: "Khan, Sohel" , "Ejzak, Richard P (Richard)" , "rtcweb@ietf.org" , "public-webrtc@w3.org" Thread-Topic: [rtcweb] JSEP-02: New offer and answer to previous offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case] Thread-Index: AQHM8AqE+28vByK84kKxG08H/gll95ZF3BIAgAAASYCAAASXgIAAGTuAgADuMECAAH0N0IAAZRbggAAhZzCAAFDIgIAAcX8AgAdZ23A= Date: Mon, 27 Feb 2012 02:14:55 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E04AD34@inba-mail01.sonusnet.com> References: <7F2072F1E0DE894DA4B517B93C6A05852C3D31BA37@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C3D31BA3A@ESESSCMS0356.eemea.ericsson.se> <4F42C2C7.3060802@jesup.org> <387F9047F55E8C42850AD6B3A7A03C6C0E040FFE@inba-mail01.sonusnet.com> <6F428EFD2B8C2F49A2FB1317291A76C11355D49C4E@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <387F9047F55E8C42850AD6B3A7A03C6C0E0412EB@inba-mail01.sonusnet.com> <6F428EFD2B8C2F49A2FB1317291A76C11355D4A115@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <387F9047F55E8C42850AD6B3A7A03C6C0E041386@inba-mail01.sonusnet.com> <837E772D16C77141BFA5FEC3F30487FF525CA77C@PACDCEXMB02.cable.comcast.com> In-Reply-To: <837E772D16C77141BFA5FEC3F30487FF525CA77C@PACDCEXMB02.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: multipart/mixed; boundary="_004_387F9047F55E8C42850AD6B3A7A03C6C0E04AD34inbamail01sonus_" MIME-Version: 1.0 X-OriginalArrivalTime: 27 Feb 2012 02:14:56.0990 (UTC) FILETIME=[99B5DFE0:01CCF4F5] Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case] 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, 27 Feb 2012 02:15:09 -0000 --_004_387F9047F55E8C42850AD6B3A7A03C6C0E04AD34inbamail01sonus_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Richard/Sohel, I attached updated 3 callflows with this mail. 1) Single offer and multiple answer 2) SIP Serial forking 3) SIP Parallel forking I have add the comment "Handling of Reliable response PRACK and 200 is not = shown for simplicity" to indicate about Standard SIP callflow. Please let m= e know your comment on this. Thanks Partha >-----Original Message----- >From: Khan, Sohel [mailto:Sohel_Khan@cable.comcast.com] >Sent: Wednesday, February 22, 2012 8:49 PM >To: Ravindran, Parthasarathi; Ejzak, Richard P (Richard); >rtcweb@ietf.org; public-webrtc@w3.org >Subject: RE: [rtcweb] JSEP-02: New offer and answer to previous offer >[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] > >Partha, > >If possible, please minimize the use of PRACK in the call flow. We would >like to have call flows simple and less chatty. > >Sohel > >-----Original Message----- >From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] >Sent: Tuesday, February 21, 2012 10:32 PM >To: Ejzak, Richard P (Richard); rtcweb@ietf.org; public-webrtc@w3.org >Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous offer >[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] > >Hi Richard, > >Thanks for your comments. I have put the focus on the offer/answer >exchange between OffererJS and OffererUA in the callflow and assumed 18x >as reliable. I'm bit afraid to write too much details about SIP in this >forum (see RTCWeb archive for more details) :-) > >I'll update the callflow with PRACK & 200. Out of the 3 requested >usecases, I have provided 1 and 3 with this assumption. I'll send 2nd >usecase of serial forking with UPDATE and updated standard callflow for >1st & 3rd usecase ASAP. > >My intention is not to violate standard but I have provided the deployed >(real-time) usecases as Cullen requested and also mentioned in the same >mail how to make those callflow standard compliance. For your concern on >signaling standard deviation discussion within WebRTC, I'll write the >separate mail. > >Thanks >Partha > >>-----Original Message----- >>From: Ejzak, Richard P (Richard) [mailto:richard.ejzak@alcatel- >>lucent.com] >>Sent: Wednesday, February 22, 2012 4:15 AM >>To: Ravindran, Parthasarathi; rtcweb@ietf.org; public-webrtc@w3.org >>Subject: RE: [rtcweb] JSEP-02: New offer and answer to previous offer >>[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] >> >>Hi Partha, >>Thanks for the call flows and explanations. >> >>For all of your flows, it would really help if any deviation from RFC >>3261 or RFC 3264 is clearly noted in your flows. Further, it would >>help to be clear when you assume reliable or unreliable provisionals, >>since that makes a big difference. You appear to usually assume >>reliable provisionals, but I want to be sure. >> >>It would also help to identify the purpose of some key operations in >>each flow when not strictly for protocol conformance. For example, >>setting some flows to "inactive" is used to avoid having multiple media >>flows when parallel forking, but this is an application choice rather >>than a protocol necessity. >> >>You state that your earlier flow violates RFC 3261, and in an earlier >>posting you insist that it should be supported because some >>implementations behave that way. I have a real problem with this. >>Standards are meant to help in avoiding exactly this kind of situation >>and I don't think that non-standard behavior should be condoned by >>rtcweb. If there is good reason to support this kind of flow then it >>should be brought to the appropriate working group for consideration >>(not rtcweb). An endpoint could achieve similar behavior by mimicking >>standard serial forking procedures (which is what I thought you >>intended but you forgot to include the interim final responses or >>byes). Why not just use a sequence of UPDATEs and avoid these hassles? >> >>The three use cases I had in mind were: >> >>1) mimicking standard serial forking from a single endpoint to realize >>the equivalent of multiple ANSWERs to a single OFFER (although separate >>OFFER/ANSWER transactions using UPDATE would be cleaner) >>2) standard serial forking (with optional UPDATEs) >>3) standard parallel forking (with optional UPDATEs) >> >>Do we really need anything other than 2) and 3)? >> >>Richard >> >>-----Original Message----- >>From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] >>Sent: Tuesday, February 21, 2012 2:51 PM >>To: Ejzak, Richard P (Richard); rtcweb@ietf.org; public-webrtc@w3.org; >>Randell Jesup >>Subject: RE: [rtcweb] JSEP-02: New offer and answer to previous offer >>[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] >> >>Hi all, >> >>Till now, I'm writing the callflow with the assumption of browser as >>RTP Endpoint. Two JSEP example call flow are attached: >> >> 1) Two 180 with SDP (answer) and second 180's dialog comes up with >2xx >>with SDP >> 2) Two 180 with SDP (answer) and first 180's dialog comes up with >>2xx with SDP >> >>The above callflows are not the only way to solve the problem but it is >>one of the way to solve this callflow. The intention of these callflows >>are to indicate that multiple answers support in JSEP facilities for >>designing SIP parallel forking kind of services. The exact intention >>is as per >>http://www.ietf.org/mail-archive/web/rtcweb/current/msg03455.html >>and as follows: >> >>1) allow a setRemoteDesc(SDP_ANSWER) to follow a >>setRemoteDesc(SDP_ANSWER) >>2) document that in this case (multiple 2xx), the JS is responsible for >>sending BYE to the previous answerer. >> >>Please let me know your comments on the callflow. >> >>Hi Richard, >> >>Thanks for your clarification in the below mail. Please read inline for >>more comments >> >>Thanks >>Partha >> >>>-----Original Message----- >>>From: Ejzak, Richard P (Richard) [mailto:richard.ejzak@alcatel- >>>lucent.com] >>>Sent: Tuesday, February 21, 2012 8:05 PM >>>To: Ravindran, Parthasarathi; rtcweb@ietf.org; public-webrtc@w3.org >>>Subject: RE: [rtcweb] JSEP-02: New offer and answer to previous offer >>>[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] >>> >>>Hi Partha, >>>Regarding my earlier email (this earlier email was not distributed on >>>the webrtc list), I do not dispute that forking must be supported by >>>all SIP endpoints. Let me rephrase my earlier questions in light of >>>your latest call flow. >>> >>>Looking at your call flow, I see that you treat the case of multiple >>>answers from the same endpoint as a serial forking case (or do I >>>misunderstand your intent?). >> >> I agree that this callflow is allowed in JSEP and it is a >>violation of RFC 3261 and not RFC 3264. I explained in detail why this >>callflow shall be allowed in http://www.ietf.org/mail- >>archive/web/rtcweb/current/msg03478.html >> >> How do you determine that this is a >>>special type of serial forking and not a parallel forking case? >> >> I won't determine it. I will just update based on the last >>active answer. >> >> We have >>>at least three use cases for multiple ANSWER and it would be helpful >>>to see how they can be handled and distinguished in SIP signaling. >>> >> Please mentioned the three of them. I'll provide the callflow >>for the same >> >>>Also, PRANSWER as currently defined seems to have no analog in SIP. >>>Is this also your understanding? >> We have the common understanding here. I'm requesting to >>remove PR_ANSWER state as it complicates JS Offer/Answer FSM still more >(See: >>http://www.ietf.org/mail-archive/web/rtcweb/current/msg03489.html). >> >> >>> >>>I don't understand your statement that "It is possible to implement >>>parallel forking by keeping only one answer active in the offerer side >>>at the given time". It would appear that an implementation of >>>parallel forking would need to keep the last answer from each dialog >active. >>>Please explain. >>> >> Hope the callflow clarifies >> >>>I look forward to your next call flow. >>> >>>Richard >>> >>>-----Original Message----- >>>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >>>Behalf Of Ravindran, Parthasarathi >>>Sent: Tuesday, February 21, 2012 12:58 AM >>>To: Randell Jesup; rtcweb@ietf.org; public-webrtc@w3.org >>>Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous offer >>>[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] >>> >>>Randell, >>> >>>It is possible to implement parallel forking by keeping only one >>>answer active in the offerer side at the given time. I attached one of >>>the example "18x with SDP and 2xx with different SDP" for your >>>reference which will map to serial forking. Please let me know your >>>concern about ICE interaction concern here. >>> >>>I'll send multiple 18x with SDP and one 2xx with SDP response JSEP >>>example using UPDATE O/A mechanism ASAP for clarity on parallel >>>forking >>>(assumption: multiple answer for single offer is supported in JSEP). >>> >>>Thanks >>>Partha >>> >>>>-----Original Message----- >>>>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >>>>Behalf Of Randell Jesup >>>>Sent: Tuesday, February 21, 2012 3:32 AM >>>>To: rtcweb@ietf.org; public-webrtc@w3.org >>>>Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous offer >>>>[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] >>>> >>>>On 2/20/2012 3:31 PM, Roman Shpount wrote: >>>>> Not to beat this horse to death, but why is it "suggested not to >>>>> have parallel forking"? WebRTC intorduces additional restrictions >>>>> on RTP stream (remote media sources and SSRCs are known in advance) >>>>> that make parallel forking implementation trivial. Only thing that >>>>> is missing is some way to clone the PeerConnection in the API. >>>> >>>>Right; parallel forking has uses. >>>> >>>>We've talked about this, but not for a while. One way to implement >>>>it would be to on each forked answer clone the state of the >>>>PeerConnection as it was with any previous answer removed. However, >>>>I'm concerned about how this will interact with the ICE, etc stuff. >>>>Someone want to throw out a suggestion? Cullen, Justin - how >>>>*should*/*could* forking work within JSEP? >>>> >>>> >>>>Aside on uses of forking: >>>>I can see some additional interesting uses for parallel forking, >>>>especially in non-phone-like usecases (games among others). The >>>>server (or another participant) could hold open an OFFER in order to >>>>forward it to any potential new partners. This might apply to a >>>>conference call as well if there's a peer-2-peer aspect (mesh, >>>>partial-mesh, etc) >>>to it. >>>> >>>>Think in a game or 2nd-life-type-sim, where you're automatically in a >>>>voice chat with anyone within hearing range, and those voice chats >>>>are done p2p by forking each player's original offer to the server, >>>>and forwarding it (forking it) to the new user, who would answer and >>>>they'd be in a call. >>>> >>>>If you wanted to get really fancy, you could even do some of the >>>>negotiation in the server and rephrase each offer as an answer to the >>>>other side, leading to a 1/2-RTT-to-the-server setup time (more-or- >>>less: >>>> >>>>player 1 server player 2 >>>>------------------------------------------------------------ >>>>| | | >>>>|--> Offer 1 ---------------->| | >>>>| |<---------- Offer 2 <----| >>>>| | | >>>>... >>>> Server decides they should talk >>>>| | | >>>>|<-- Answer(Offer 2) <--------|-----> Answer(Offer 1)-->| >>>>|<------------------------- media --------------------->| >>>> >>>>Even if this is initiated by a player, there are equivalent graphs >>>>that use 1/2 RTT (through the server to other player) to set up >>channels. >>>> >>>>I should note however that ICE overhead may well swamp this fancy >>>>setup and it may be over-reaching, but each 1/2 RTT removed is >>>>significant, so there may be uses. >>>> >>>>> _____________ >>>>> Roman Shpount >>>>> >>>>> >>>>> On Mon, Feb 20, 2012 at 3:14 PM, Christer Holmberg >>>>> >>>> > >>>>> wrote: >>>>> >>>>> >>>>> Hi, >>>>> >>>>> Just to clarify: the new offer is for the same "session" as the >>>>> previous offer, and is supposed to replace the previous offer. >>>>> >>>>> The browser can of course send a just-audio offer somewhere, >>>>> and >>>a >>>>> just-video offer somewhere else, but would those even be >>>>associated >>>>> with the same PeerConnection? I thought we wanted only one >>>>> offer/answer, which is the reason it has been suggested e.g. >>>>> not >>>>to >>>>> support paralell forking in the browser. >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> ________________________________________ >>>>> From: I=F1aki Baz Castillo [ibc@aliax.net ] >>>>> Sent: Monday, February 20, 2012 10:13 PM >>>>> To: Christer Holmberg >>>>> Cc: Justin Uberti; rtcweb@ietf.org ; >>>>> public-webrtc@w3.org >>>>> Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous >>>>> offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case] >>>>> >>>>> 2012/2/20 Christer Holmberg >>>> >: >>>>> > Q1. When the JS app requests the new offer (o-2), I assume >>all >>>>> resources etc associated with o-1 will be released (unless they >>>>are >>>>> also needed for o-2, that is). >>>>> >>>>> Does it mean that the browser is just capable of having *one* >>>>> multimedia session at the same time? Well, in SIP world this >>>>typically >>>>> means putting on-hold the previous call so, indeed, resources >>>>would be >>>>> released. >>>>> >>>>> But, why couldn't the browser send a just-audio offer somewhere >>>>and a >>>>> just-video offer to other destination at the same time? >>>>> >>>>> -- >>>>> I=F1aki Baz Castillo >>>>> > >>>>> _______________________________________________ >>>>> 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 >>>> >>>> >>>>-- >>>>Randell Jesup >>>>randell-ietf@jesup.org >>>>_______________________________________________ >>>>rtcweb mailing list >>>>rtcweb@ietf.org >>>>https://www.ietf.org/mailman/listinfo/rtcweb --_004_387F9047F55E8C42850AD6B3A7A03C6C0E04AD34inbamail01sonus_ Content-Type: text/plain; name="Single Offer Multiple answer callflow.txt" Content-Description: Single Offer Multiple answer callflow.txt Content-Disposition: attachment; filename="Single Offer Multiple answer callflow.txt"; size=2752; creation-date="Sat, 18 Feb 2012 17:22:50 GMT"; modification-date="Sun, 19 Feb 2012 18:21:30 GMT" Content-Transfer-Encoding: base64 VGhpcyBleGFtcGxlIGRlbW9uc3RyYXRlcyBtdWx0aXBsZSBhbnN3ZXIgZm9yIHNpbmdsZSBvZmZl ciwgd2l0aG91dCB0aGUgdXNlIG9mIHRyaWNrbGUNCiAgIGNhbmRpZGF0ZXMNCg0KICAgLy8gQ2Fs bCBpcyBpbml0aWF0ZWQgdG93YXJkIEFuc3dlcmVyDQogICBPZmZlcmVySlMtPk9mZmVyZXJVQTog ICBwYyA9IG5ldyBQZWVyQ29ubmVjdGlvbigpOw0KICAgT2ZmZXJlckpTLT5PZmZlcmVyVUE6ICAg cGMuYWRkU3RyZWFtKGxvY2FsU3RyZWFtLCBudWxsKTsNCiAgIE9mZmVyZXJKUy0+T2ZmZXJlclVB OiAgIHBjLnN0YXJ0SWNlKCk7DQogICBPZmZlcmVyVUEtPk9mZmVyZXJKUzogICBpY2VDYWxsYmFj ayhjYW5kaWRhdGUsIGZhbHNlKTsNCiAgIE9mZmVyZXJKUy0+T2ZmZXJlclVBOiAgIG9mZmVyID0g cGMuY3JlYXRlT2ZmZXIobnVsbCk7DQogICBPZmZlcmVySlMtPk9mZmVyZXJVQTogICBwYy5zZXRM b2NhbERlc2NyaXB0aW9uKFNEUF9PRkZFUiwgb2ZmZXIudG9TZHAoKSk7DQogICBPZmZlcmVySlMt PkFuc3dlcmVySlM6ICB7InR5cGUiOiJPRkZFUiIsICJzZHAiOiI8b2ZmZXI+In0NCg0KICAgLy8g T0ZGRVIgYXJyaXZlcyBhdCBBbnN3ZXJlcjENCiAgIEFuc3dlcmVyMUpTLT5BbnN3ZXJlcjFVQTog cGMgPSBuZXcgUGVlckNvbm5lY3Rpb24oKTsNCiAgIEFuc3dlcmVyMUpTLT5BbnN3ZXJlcjFVQTog cGMuc2V0UmVtb3RlRGVzY3JpcHRpb24oU0RQX09GRkVSLCBtc2cuc2RwKTsNCiAgIEFuc3dlcmVy MVVBLT5BbnN3ZXJlcjFKUzogb25hZGRzdHJlYW0ocmVtb3RlU3RyZWFtKTsNCiAgIEFuc3dlcmVy MUpTLT5BbnN3ZXJlcjFVQTogcGMuc3RhcnRJY2UoKTsNCiAgIEFuc3dlcmVyMVVBLT5PZmZlcmVy VUE6ICBpY2VDYWxsYmFjayhjYW5kaWRhdGUxLCBmYWxzZSk7DQoNCiAgIC8vIE9GRkVSIGFycml2 ZXMgYXQgQW5zd2VyZXIyDQogICBBbnN3ZXJlcjJKUy0+QW5zd2VyZXIyVUE6IHBjID0gbmV3IFBl ZXJDb25uZWN0aW9uKCk7DQogICBBbnN3ZXJlcjJKUy0+QW5zd2VyZXIyVUE6IHBjLnNldFJlbW90 ZURlc2NyaXB0aW9uKFNEUF9PRkZFUiwgbXNnLnNkcCk7DQogICBBbnN3ZXJlcjJVQS0+QW5zd2Vy ZXIySlM6IG9uYWRkc3RyZWFtKHJlbW90ZVN0cmVhbSk7DQogICBBbnN3ZXJlcjJKUy0+QW5zd2Vy ZXIyVUE6IHBjLnN0YXJ0SWNlKCk7DQogICBBbnN3ZXJlcjJVQS0+T2ZmZXJlclVBOiAgaWNlQ2Fs bGJhY2soY2FuZGlkYXRlMiwgZmFsc2UpOw0KDQogICAvLyBBbnN3ZXJlcjEgYWNjZXB0cyBjYWxs DQogICBBbnN3ZXJlcjFKUy0+QW5zd2VyZXIxVUE6IHBlZXIuYWRkU3RyZWFtKGxvY2FsU3RyZWFt LCBudWxsKTsNCiAgIEFuc3dlcmVyMUpTLT5BbnN3ZXJlcjFVQTogYW5zd2VyMSA9IHBlZXIuY3Jl YXRlQW5zd2VyKG1zZy5vZmZlciwgbnVsbCk7DQogICBBbnN3ZXJlcjFKUy0+QW5zd2VyZXIxVUE6 IHBlZXIuc2V0TG9jYWxEZXNjcmlwdGlvbihTRFBfQU5TV0VSLCBhbnN3ZXIxKTsNCiAgIEFuc3dl cmVyMUpTLT5PZmZlcmVySlM6ICB7InR5cGUiOiJBTlNXRVIiLCJzZHAiOiI8YW5zd2VyMT4ifQ0K DQogICAvLyBBTlNXRVIxIGFycml2ZXMgYXQgT2ZmZXJlcg0KICAgT2ZmZXJlckpTLT5PZmZlcmVy VUE6ICAgcGVlci5zZXRSZW1vdGVEZXNjcmlwdGlvbihBTlNXRVIsIGFuc3dlcjEpOyANCiAgIE9m ZmVyZXJVQS0+T2ZmZXJlckpTOiAgIG9uYWRkc3RyZWFtKHJlbW90ZVN0cmVhbSk7DQoNCiAgIC8v IElDRSBDb21wbGV0ZXMgKGF0IEFuc3dlcmVyKQ0KICAgQW5zd2VyZXIxVUEtPkFuc3dlcmVyMUpT OiBvbm9wZW4oKTsNCiAgIEFuc3dlcmVyMVVBLT5PZmZlcmVyVUE6ICBNZWRpYQ0KDQoNCiAgIC8v IElDRSBDb21wbGV0ZXMgKGF0IE9mZmVyZXIpDQogICBPZmZlcmVyVUEtPk9mZmVyZXJKUzogICBv bm9wZW4oKTsNCiAgIE9mZmVyZXJKUy0+QW5zd2VyZXIxSlM6ICB7InR5cGUiOiJPSyIgfQ0KICAg T2ZmZXJlclVBLT5BbnN3ZXJlcjFVQTogIE1lZGlhDQoNCg0KICAgLy8gQW5zd2VyZXIyIGFjY2Vw dHMgY2FsbA0KICAgQW5zd2VyZXIySlMtPkFuc3dlcmVyMlVBOiBwZWVyLmFkZFN0cmVhbShsb2Nh bFN0cmVhbSwgbnVsbCk7DQogICBBbnN3ZXJlcjJKUy0+QW5zd2VyZXIyVUE6IGFuc3dlcjEgPSBw ZWVyLmNyZWF0ZUFuc3dlcihtc2cub2ZmZXIsIG51bGwpOw0KICAgQW5zd2VyZXIySlMtPkFuc3dl cmVyMlVBOiBwZWVyLnNldExvY2FsRGVzY3JpcHRpb24oU0RQX0FOU1dFUiwgYW5zd2VyMik7DQog ICBBbnN3ZXJlcjJKUy0+T2ZmZXJlckpTOiAgeyJ0eXBlIjoiQU5TV0VSIiwic2RwIjoiPGFuc3dl cjI+In0NCg0KICAgLy8gQU5TV0VSMiBhcnJpdmVzIGF0IE9mZmVyZXINCiAgIE9mZmVyZXJKUy0+ T2ZmZXJlclVBOiAgIHBlZXIuc2V0UmVtb3RlRGVzY3JpcHRpb24oQU5TV0VSLCBhbnN3ZXIyKTsg DQogICBPZmZlcmVyVUEtPk9mZmVyZXJKUzogICBvbmFkZHN0cmVhbShyZW1vdGVTdHJlYW0pOw0K ICAgT2ZmZXJlckpTLT5BbnN3ZXJlcjFKUzogIEJZRQ0KDQoNCiAgIC8vIElDRSBDb21wbGV0ZXMg KGF0IEFuc3dlcmVyMikNCiAgIEFuc3dlcmVyMlVBLT5BbnN3ZXJlcjJKUzogb25vcGVuKCk7DQog ICBBbnN3ZXJlcjJVQS0+T2ZmZXJlclVBOiAgTWVkaWENCg0KDQogICAvLyBJQ0UgQ29tcGxldGVz IChhdCBPZmZlcmVyKQ0KICAgT2ZmZXJlclVBLT5PZmZlcmVySlM6ICAgb25vcGVuKCk7DQogICBP ZmZlcmVySlMtPkFuc3dlcmVyMkpTOiAgeyJ0eXBlIjoiT0siIH0NCiAgIE9mZmVyZXJVQS0+QW5z d2VyZXIyVUE6ICBNZWRpYQ== --_004_387F9047F55E8C42850AD6B3A7A03C6C0E04AD34inbamail01sonus_ Content-Type: text/plain; name="Serial forking with multiple 18x and 2xx with SDP.txt" Content-Description: Serial forking with multiple 18x and 2xx with SDP.txt Content-Disposition: attachment; filename="Serial forking with multiple 18x and 2xx with SDP.txt"; size=2405; creation-date="Thu, 23 Feb 2012 17:11:39 GMT"; modification-date="Mon, 27 Feb 2012 02:12:19 GMT" Content-Transfer-Encoding: base64 SGFuZGxpbmcgU2VyaWFsIGZvcmtpbmcgd2l0aCBtdWx0aXBsZSAxOHggd2l0aCBTRFAgYW5kIDJ4 eCB3aXRoIFNEUA0KDQogICBUaGlzIGV4YW1wbGUgZGVtb25zdHJhdGVzIGhvdyBNdWx0aXBsZSAx OHggd2l0aCBTRFAgYW5kIDJ4eCB3aXRoIFNEcCBpbiANCiAgIHNlcmlhbCBmb3JraW5nIGNvdWxk IGJlIGhhbmRsZWQ7IGZvciBzaW1wbGljaXR5LCBvbmx5IHRoZSBvZmZlcmVyIHNpZGUgb2YgDQog ICB0aGUgY2FsbCBpcyBzaG93bi4NCg0KICAgLy8gQ2FsbCBpcyBpbml0aWF0ZWQgdG93YXJkIEFu c3dlcmVyDQogICBPZmZlcmVySlMtPk9mZmVyZXJVQTogICBwYyA9IG5ldyBQZWVyQ29ubmVjdGlv bigpOw0KICAgT2ZmZXJlckpTLT5PZmZlcmVyVUE6ICAgcGMuYWRkU3RyZWFtKGxvY2FsU3RyZWFt LCBudWxsKTsNCiAgIE9mZmVyZXJKUy0+T2ZmZXJlclVBOiAgIHBjLnN0YXJ0SWNlKCk7DQogICBP ZmZlcmVyVUEtPk9mZmVyZXJKUzogICBpY2VDYWxsYmFjayhjYW5kaWRhdGUsIGZhbHNlKTsNCiAg IE9mZmVyZXJKUy0+T2ZmZXJlclVBOiAgIG9mZmVyID0gcGMuY3JlYXRlT2ZmZXIobnVsbCk7DQog ICBPZmZlcmVySlMtPk9mZmVyZXJVQTogICBwYy5zZXRMb2NhbERlc2NyaXB0aW9uKFNEUF9PRkZF Uiwgb2ZmZXIpOw0KICAgT2ZmZXJlckpTOiAgICAgICAgICAgICAgSU5WSVRFID0gY3JlYXRlSW52 aXRlKG9mZmVyKTsNCiAgIE9mZmVyZXJKUy0+QW5zd2VyZXJKUzogIFNJUCBJTlZJVEUgdy8gU0RQ DQoNCiAgIC8vIDE4MyBTZXNzaW9uIHByb2dyZXNzIHcvU0RQMSBmcm9tIGFuc3dlcmVyMSBpcyBy ZWNlaXZlZCBieSBvZmZlcmVyLA0KICAgLy8gSGFuZGxpbmcgb2YgUmVsaWFibGUgcmVzcG9uc2Ug UFJBQ0sgYW5kIDIwMCBpcyBub3Qgc2hvd24gZm9yIHNpbXBsaWNpdHkgDQogICBPZmZlcmVySlM6 ICAgICAgICAgICAgICBhbnN3ZXIxID0gcGFyc2VSZXNwb25zZShzaXApOw0KICAgT2ZmZXJlckpT LT5PZmZlcmVyVUE6ICAgcGMuc2V0UmVtb3RlRGVzY3JpcHRpb24oU0RQX0FOU1dFUiwgYW5zd2Vy MSk7DQogICBPZmZlcmVyVUEtPk9mZmVyZXJKUzogICBvbmFkZHN0cmVhbShyZW1vdGVTdHJlYW0p Ow0KDQogICAvLyBJQ0UgQ29tcGxldGVzIChhdCBPZmZlcmVyIGZvciBhbnN3ZXIxKQ0KICAgT2Zm ZXJlclVBLT5PZmZlcmVySlM6ICAgb25vcGVuKCk7DQogICBPZmZlcmVyVUEtPkFuc3dlcmVyMVVB OiAgTWVkaWENCg0KICAgLy8gVVBEQVRFIHcvU0RQMiBmcm9tIGFuc3dlcmVyMSBpcyByZWNlaXZl ZCBieSBvZmZlcmVyDQogICBPZmZlcmVySlM6ICAgICAgICAgICAgICBhbnN3ZXIyID0gcGFyc2VS ZXNwb25zZShzaXApOw0KICAgT2ZmZXJlckpTLT5PZmZlcmVyVUE6ICAgcGMuc2V0UmVtb3RlRGVz Y3JpcHRpb24oU0RQX0FOU1dFUiwgYW5zd2VyMik7DQogICBPZmZlcmVyVUEtPk9mZmVyZXJKUzog ICBvbmFkZHN0cmVhbShyZW1vdGVTdHJlYW0pOw0KICAgT2ZmZXJlckpTLT5BbnN3ZXJlcjFKUzog IDIwMCBPayAoVVBEQVRFKQ0KDQoNCiAgIC8vIDE4MCBSaW5naW5nIGlzIHJlY2VpdmVkIHcvU0RQ MiBmcm9tIGFuc3dlcmVyMSBieSBvZmZlcmVyDQogICBPZmZlcmVySlMtPkFuc3dlcmVyMUpTOiAg UFJBQ0sNCiAgIC8vIE5vIGFjdGlvbiByZXF1aXJlZCBmb3IgMjAwIE9mIFBSQUNLDQogICBPZmZl ckpTOglwYXJzZVJlc3BvbnNlKHNpcCk7DQogICAgICAgICAgICAgICAgICAgDQogICAvLyBJQ0Ug Q29tcGxldGVzIChhdCBPZmZlcmVyIGZvciBhbnN3ZXIyKQ0KICAgT2ZmZXJlclVBLT5PZmZlcmVy SlM6ICAgb25vcGVuKCk7DQogICBPZmZlcmVyVUEtPkFuc3dlcmVyMVVBOiAgTWVkaWENCg0KICAg Ly8gVVBEQVRFIHcvU0RQMyBmcm9tIGFuc3dlcmVyMSBpcyByZWNlaXZlZCBieSBvZmZlcmVyDQog ICBPZmZlcmVySlM6ICAgICAgICAgICAgICBhbnN3ZXIxID0gcGFyc2VSZXNwb25zZShzaXApOw0K ICAgT2ZmZXJlckpTLT5PZmZlcmVyVUE6ICAgcGMuc2V0UmVtb3RlRGVzY3JpcHRpb24oU0RQX0FO U1dFUiwgYW5zd2VyMik7DQogICAvL29uVXBkYXRlc3RyZWFtPw0KICAgT2ZmZXJlclVBLT5PZmZl cmVySlM6ICAgb25hZGRzdHJlYW0ocmVtb3RlU3RyZWFtKTsNCiAgIE9mZmVyZXJKUy0+QW5zd2Vy ZXIxSlM6ICAyMDAgT2sgKFVQREFURSk7DQogICAgIA0KICAgLy8gMjAwIE9LIGZvciBVUERBVEUg aXMgcmVjZWl2ZWQgYnkgb2ZmZXJlciwgdy9TRFAzIGZyb20gYW5zd2VyZXIxDQogICBvZmZlcmVy SlM6ICAgICAgIGFuc3dlcjMgPSBwYXJzZVJlc3BvbnNlKHNpcCk7ICAgICAgICAgICANCg0KICAg Ly8gMjAwIE9LIGFycml2ZXMgYXQgT2ZmZXJlciwgdy9zZHAyIGZyb20gYW5zd2VyZXIxDQogICBP ZmZlcmVySlMtPkFuc3dlcmVyMUpTOiAgQUNLDQogICBPZmZlcmVySlMtPkFuc3dlcmVyMUpTOiAg QllFDQoNCg0KDQo= --_004_387F9047F55E8C42850AD6B3A7A03C6C0E04AD34inbamail01sonus_ Content-Type: text/plain; name="Parallel forking with Mutliple 18x and 2xx with SDP.txt" Content-Description: Parallel forking with Mutliple 18x and 2xx with SDP.txt Content-Disposition: attachment; filename="Parallel forking with Mutliple 18x and 2xx with SDP.txt"; size=2178; creation-date="Fri, 24 Feb 2012 01:27:19 GMT"; modification-date="Mon, 27 Feb 2012 02:10:15 GMT" Content-Transfer-Encoding: base64 SGFuZGxpbmcgUGFyYWxsZWwgZm9ya2luZyB3aXRoIE11bHRpcGxlIDE4eCB3aXRoIFNEUCBhbmQg Mnh4IHdpdGggU0RQLCB1c2luZyBTSVANCg0KICAgVGhpcyBleGFtcGxlIGRlbW9uc3RyYXRlcyBo b3cgTXVsdGlwbGUgMTh4IHdpdGggU0RQIGNvdWxkIGJlIGhhbmRsZWQ7IGZvcg0KICAgc2ltcGxp Y2l0eSwgb25seSB0aGUgb2ZmZXJlciBzaWRlIG9mIHRoZSBjYWxsIGlzIHNob3duLg0KDQogICAv LyBDYWxsIGlzIGluaXRpYXRlZCB0b3dhcmQgQW5zd2VyZXINCiAgIE9mZmVyZXJKUy0+T2ZmZXJl clVBOiAgIHBjID0gbmV3IFBlZXJDb25uZWN0aW9uKCk7DQogICBPZmZlcmVySlMtPk9mZmVyZXJV QTogICBwYy5hZGRTdHJlYW0obG9jYWxTdHJlYW0sIG51bGwpOw0KICAgT2ZmZXJlckpTLT5PZmZl cmVyVUE6ICAgcGMuc3RhcnRJY2UoKTsNCiAgIE9mZmVyZXJVQS0+T2ZmZXJlckpTOiAgIGljZUNh bGxiYWNrKGNhbmRpZGF0ZSwgZmFsc2UpOw0KICAgT2ZmZXJlckpTLT5PZmZlcmVyVUE6ICAgb2Zm ZXIgPSBwYy5jcmVhdGVPZmZlcihudWxsKTsNCiAgIE9mZmVyZXJKUy0+T2ZmZXJlclVBOiAgIHBj LnNldExvY2FsRGVzY3JpcHRpb24oU0RQX09GRkVSLCBvZmZlcik7DQogICBPZmZlcmVySlM6ICAg ICAgICAgICAgICBJTlZJVEUgPSBjcmVhdGVJbnZpdGUob2ZmZXIpOw0KICAgT2ZmZXJlckpTLT5B bnN3ZXJlckpTOiAgU0lQIElOVklURSB3LyBTRFANCg0KICAgLy8gMTgwIFJpbmdpbmcgdy9TRFAx IGZyb20gYW5zd2VyZXIxIGlzIHJlY2VpdmVkIGJ5IG9mZmVyZXIsDQogICAvLyBIYW5kbGluZyBv ZiBSZWxpYWJsZSByZXNwb25zZSBQUkFDSyBhbmQgMjAwIGlzIG5vdCBzaG93biBmb3Igc2ltcGxp Y2l0eSANCiAgIE9mZmVyZXJKUzogICAgICAgICAgICAgIGFuc3dlcjEgPSBwYXJzZVJlc3BvbnNl KHNpcCk7DQogICBPZmZlcmVySlMtPk9mZmVyZXJVQTogICBwYy5zZXRSZW1vdGVEZXNjcmlwdGlv bihTRFBfQU5TV0VSLCBhbnN3ZXIxKTsNCiAgIE9mZmVyZXJVQS0+T2ZmZXJlckpTOiAgIG9uYWRk c3RyZWFtKHJlbW90ZVN0cmVhbSk7DQogDQoNCiAgIC8vIElDRSBDb21wbGV0ZXMgKGF0IE9mZmVy ZXIgZm9yIGFuc3dlcjEpDQogICBPZmZlcmVyVUEtPk9mZmVyZXJKUzogICBvbm9wZW4oKTsNCiAg IE9mZmVyZXJVQS0+QW5zd2VyZXIxVUE6ICBNZWRpYQ0KDQogICAvLyAxODAgUmluZ2luZyBpcyB3 L1NEUDIgZnJvbSBhbnN3ZXJlcjIgcmVjZWl2ZWQgYnkgb2ZmZXJlcg0KICAgT2ZmZXJlckpTOiAg ICAgICAgICAgICAgYW5zd2VyMiA9IHBhcnNlUmVzcG9uc2Uoc2lwKTsNCiAgIE9mZmVyZXJKUy0+ T2ZmZXJlclVBOiAgIHBjLnNldFJlbW90ZURlc2NyaXB0aW9uKFNEUF9BTlNXRVIsIGFuc3dlcjIp Ow0KICAgT2ZmZXJlclVBLT5PZmZlcmVySlM6ICAgb25hZGRzdHJlYW0ocmVtb3RlU3RyZWFtKTsN CiAgIC8vIFVQREFURSBpcyBzZW50IG91dCB0byBhdm9pZCB1bm5lY2Vzc2FyeSBtZWRpYSBzdHJl YW0gZnJvbSBhbnN3ZXJlcjENCiAgIE9mZmVyZXJKUzogICAgICAgICAgICAgIG9mZmVyX2Fuc3dl cjEgPSBjcmVhdGVJbmFjdGl2ZURpcmVjdGlvblNkcChhbnN3ZXIxKTsgICAgICAgIA0KICAgT2Zm ZXJlckpTOgkJICAgVVBEQVRFID0gY3JlYXRlVXBkYXRlKG9mZmVyX2Fuc3dlcjEpOyANCiAgIE9m ZmVyZXJKUy0+QW5zd2VyZXIxSlM6ICBTSVAgVVBEQVRFIHcvU0RQDQogICAgICAgICAgICAgICAg ICAgDQoNCiAgIC8vIElDRSBDb21wbGV0ZXMgKGF0IE9mZmVyZXIgZm9yIGFuc3dlcjINCiAgIE9m ZmVyZXJVQS0+T2ZmZXJlckpTOiAgIG9ub3BlbigpOw0KICAgT2ZmZXJlclVBLT5BbnN3ZXJlcjJV QTogIE1lZGlhDQoNCiAgICAgDQogICAvLyAyMDAgT0sgZm9yIFVQREFURSBpcyByZWNlaXZlZCBi eSBvZmZlcmVyLCB3L3NkcDMgZnJvbSBhbnN3ZXJlcjENCiAgIC8vIE5vIFVQREFURSBvbiBPZmZl cmVyVUEgYXMgaXQgaXMgaG9sZCByZXF1ZXN0IHRvd2FyZHMgYW5zd2VyZXIxLiANCiAgIG9mZmVy ZXJKUzogICAgICAgYW5zd2VyMyA9IHBhcnNlUmVzcG9uc2Uoc2lwKSAgICAgICAgICAgDQoNCiAg IC8vIDIwMCBPSyBhcnJpdmVzIGF0IE9mZmVyZXIsIHcvc2RwMiBmcm9tIGFuc3dlcmVyMg0KICAg T2ZmZXJlckpTLT5BbnN3ZXJlcjJKUzogIEFDSw0KICAgT2ZmZXJlckpTLT5BbnN3ZXJlcjFKUzog IEJZRQ0KDQoNCg0K --_004_387F9047F55E8C42850AD6B3A7A03C6C0E04AD34inbamail01sonus_-- From pravindran@sonusnet.com Sun Feb 26 18:18: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 C712A21F849D for ; Sun, 26 Feb 2012 18:18:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[AWL=-1.093, BAYES_20=-0.74, J_CHICKENPOX_65=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 6NdFJo5ANCbv for ; Sun, 26 Feb 2012 18:18:44 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 774E221F84A5 for ; Sun, 26 Feb 2012 18:18:44 -0800 (PST) Received: from sonusmail05.sonusnet.com (sonusmail05.sonusnet.com [10.128.32.155]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q1R2JTaV004831; Sun, 26 Feb 2012 21:19:29 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 26 Feb 2012 21:18:40 -0500 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 27 Feb 2012 07:48:37 +0530 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; Mon, 27 Feb 2012 07:48:36 +0530 From: "Ravindran, Parthasarathi" To: Jim Barnett , EJZAK Richard , "rtcweb@ietf.org" , "public-webrtc@w3.org" , Randell Jesup Thread-Topic: [rtcweb] JSEP-02: New offer and answer to previous offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case] Thread-Index: AQHM8AqE+28vByK84kKxG08H/gll95ZF3BIAgAAASYCAAASXgIAAGTuAgADuMECAAH0N0IAAZRbggAAO+MCACDHn4A== Date: Mon, 27 Feb 2012 02:18:36 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E04CD57@inba-mail01.sonusnet.com> References: <7F2072F1E0DE894DA4B517B93C6A05852C3D31BA37@ESESSCMS0356.eemea.ericsson.se><7F2072F1E0DE894DA4B517B93C6A05852C3D31BA3A@ESESSCMS0356.eemea.ericsson.se><4F42C2C7.3060802@jesup.org><387F9047F55E8C42850AD6B3A7A03C6C0E040FFE@inba-mail01.sonusnet.com><6F428EFD2B8C2F49A2FB1317291A76C11355D49C4E@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <387F9047F55E8C42850AD6B3A7A03C6C0E0412EB@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: [121.242.142.186] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 27 Feb 2012 02:18:37.0435 (UTC) FILETIME=[1D1B1CB0:01CCF4F6] Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case] 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, 27 Feb 2012 02:18:45 -0000 Jim, As you expect, there is no ICE restart in the callflow. My understanding ab= out onOpen callback is that it is received in JS whenever the connectivity = check is completed with the peer and in case of multiple answer, the callba= ck will be thrown per peer connectivity check completion.=20 Thanks Partha >-----Original Message----- >From: Jim Barnett [mailto:Jim.Barnett@genesyslab.com] >Sent: Wednesday, February 22, 2012 2:43 AM >To: Ravindran, Parthasarathi; EJZAK Richard; rtcweb@ietf.org; public- >webrtc@w3.org; Randell Jesup >Subject: RE: [rtcweb] JSEP-02: New offer and answer to previous offer >[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] > >One detail on the examples. As I understand section 5.1.3 of the JSEP >draft, the second argument to iceCallback is a flag indicating whether >more ICE candidates are coming. So when iceCallback is called with >'false' as the second argument, it means ICE is done. In line 10 of >your examples, I see such a callback, but then later in the example at >line 21 I see "ICE completes (at Offerer)". Has ICE somehow been >restarted in the interim, or am I misunderstanding the example (or >section 5.1.3)? > >- Jim > >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of Ravindran, Parthasarathi >Sent: Tuesday, February 21, 2012 3:51 PM >To: EJZAK Richard; rtcweb@ietf.org; public-webrtc@w3.org; Randell Jesup >Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous offer >[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] > >Hi all, > >Till now, I'm writing the callflow with the assumption of browser as RTP >Endpoint. Two JSEP example call flow are attached: > > 1) Two 180 with SDP (answer) and second 180's dialog comes up with >2xx with SDP > 2) Two 180 with SDP (answer) and first 180's dialog comes up with >2xx with SDP > >The above callflows are not the only way to solve the problem but it is >one of the way to solve this callflow. The intention of these callflows >are to indicate that multiple answers support in JSEP facilities for >designing SIP parallel forking kind of services. The exact intention is >as per http://www.ietf.org/mail-archive/web/rtcweb/current/msg03455.html >and as follows: > >1) allow a setRemoteDesc(SDP_ANSWER) to follow a >setRemoteDesc(SDP_ANSWER) >2) document that in this case (multiple 2xx), the JS is responsible for >sending BYE to the previous answerer. > >Please let me know your comments on the callflow. > >Hi Richard, > >Thanks for your clarification in the below mail. Please read inline for >more comments > >Thanks >Partha > >>-----Original Message----- >>From: Ejzak, Richard P (Richard) [mailto:richard.ejzak@alcatel- >>lucent.com] >>Sent: Tuesday, February 21, 2012 8:05 PM >>To: Ravindran, Parthasarathi; rtcweb@ietf.org; public-webrtc@w3.org >>Subject: RE: [rtcweb] JSEP-02: New offer and answer to previous offer >>[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] >> >>Hi Partha, >>Regarding my earlier email (this earlier email was not distributed on >>the webrtc list), I do not dispute that forking must be supported by >>all SIP endpoints. Let me rephrase my earlier questions in light of >>your latest call flow. >> >>Looking at your call flow, I see that you treat the case of multiple >>answers from the same endpoint as a serial forking case (or do I >>misunderstand your intent?). > > I agree that this callflow is allowed in JSEP and it is a >violation of RFC 3261 and not RFC 3264. I explained in detail why this >callflow shall be allowed in http://www.ietf.org/mail- >archive/web/rtcweb/current/msg03478.html > > How do you determine that this is a >>special type of serial forking and not a parallel forking case? > > I won't determine it. I will just update based on the last >active answer. > > We have >>at least three use cases for multiple ANSWER and it would be helpful to >>see how they can be handled and distinguished in SIP signaling. >> > Please mentioned the three of them. I'll provide the callflow >for the same > >>Also, PRANSWER as currently defined seems to have no analog in SIP. Is >>this also your understanding? > We have the common understanding here. I'm requesting to remove >PR_ANSWER state as it complicates JS Offer/Answer FSM still more (See: >http://www.ietf.org/mail-archive/web/rtcweb/current/msg03489.html). > > >> >>I don't understand your statement that "It is possible to implement >>parallel forking by keeping only one answer active in the offerer side >>at the given time". It would appear that an implementation of parallel >>forking would need to keep the last answer from each dialog active. >>Please explain. >> > Hope the callflow clarifies > >>I look forward to your next call flow. >> >>Richard >> >>-----Original Message----- >>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >>Behalf Of Ravindran, Parthasarathi >>Sent: Tuesday, February 21, 2012 12:58 AM >>To: Randell Jesup; rtcweb@ietf.org; public-webrtc@w3.org >>Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous offer >>[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] >> >>Randell, >> >>It is possible to implement parallel forking by keeping only one answer >>active in the offerer side at the given time. I attached one of the >>example "18x with SDP and 2xx with different SDP" for your reference >>which will map to serial forking. Please let me know your concern about >>ICE interaction concern here. >> >>I'll send multiple 18x with SDP and one 2xx with SDP response JSEP >>example using UPDATE O/A mechanism ASAP for clarity on parallel forking >>(assumption: multiple answer for single offer is supported in JSEP). >> >>Thanks >>Partha >> >>>-----Original Message----- >>>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >>>Behalf Of Randell Jesup >>>Sent: Tuesday, February 21, 2012 3:32 AM >>>To: rtcweb@ietf.org; public-webrtc@w3.org >>>Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous offer >>>[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] >>> >>>On 2/20/2012 3:31 PM, Roman Shpount wrote: >>>> Not to beat this horse to death, but why is it "suggested not to >>>> have parallel forking"? WebRTC intorduces additional restrictions on >>>> RTP stream (remote media sources and SSRCs are known in advance) >>>> that make parallel forking implementation trivial. Only thing that >>>> is missing is some way to clone the PeerConnection in the API. >>> >>>Right; parallel forking has uses. >>> >>>We've talked about this, but not for a while. One way to implement it >>>would be to on each forked answer clone the state of the >>>PeerConnection as it was with any previous answer removed. However, >>>I'm concerned about how this will interact with the ICE, etc stuff. >>>Someone want to throw out a suggestion? Cullen, Justin - how >>>*should*/*could* forking work within JSEP? >>> >>> >>>Aside on uses of forking: >>>I can see some additional interesting uses for parallel forking, >>>especially in non-phone-like usecases (games among others). The >>>server (or another participant) could hold open an OFFER in order to >>>forward it to any potential new partners. This might apply to a >>>conference call as well if there's a peer-2-peer aspect (mesh, >>>partial-mesh, etc) >>to it. >>> >>>Think in a game or 2nd-life-type-sim, where you're automatically in a >>>voice chat with anyone within hearing range, and those voice chats are >>>done p2p by forking each player's original offer to the server, and >>>forwarding it (forking it) to the new user, who would answer and >>>they'd be in a call. >>> >>>If you wanted to get really fancy, you could even do some of the >>>negotiation in the server and rephrase each offer as an answer to the >>>other side, leading to a 1/2-RTT-to-the-server setup time (more-or- >>less: >>> >>>player 1 server player 2 >>>------------------------------------------------------------ >>>| | | >>>|--> Offer 1 ---------------->| | >>>| |<---------- Offer 2 <----| >>>| | | >>>... >>> Server decides they should talk >>>| | | >>>|<-- Answer(Offer 2) <--------|-----> Answer(Offer 1)-->| >>>|<------------------------- media --------------------->| >>> >>>Even if this is initiated by a player, there are equivalent graphs >>>that use 1/2 RTT (through the server to other player) to set up >channels. >>> >>>I should note however that ICE overhead may well swamp this fancy >>>setup and it may be over-reaching, but each 1/2 RTT removed is >>>significant, so there may be uses. >>> >>>> _____________ >>>> Roman Shpount >>>> >>>> >>>> On Mon, Feb 20, 2012 at 3:14 PM, Christer Holmberg >>>> >>> > >>>> wrote: >>>> >>>> >>>> Hi, >>>> >>>> Just to clarify: the new offer is for the same "session" as the >>>> previous offer, and is supposed to replace the previous offer. >>>> >>>> The browser can of course send a just-audio offer somewhere, and >>a >>>> just-video offer somewhere else, but would those even be >>>associated >>>> with the same PeerConnection? I thought we wanted only one >>>> offer/answer, which is the reason it has been suggested e.g. not >>>to >>>> support paralell forking in the browser. >>>> >>>> Regards, >>>> >>>> Christer >>>> ________________________________________ >>>> From: I=F1aki Baz Castillo [ibc@aliax.net ] >>>> Sent: Monday, February 20, 2012 10:13 PM >>>> To: Christer Holmberg >>>> Cc: Justin Uberti; rtcweb@ietf.org ; >>>> public-webrtc@w3.org >>>> Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous >>>> offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case] >>>> >>>> 2012/2/20 Christer Holmberg >>> >: >>>> > Q1. When the JS app requests the new offer (o-2), I assume >all >>>> resources etc associated with o-1 will be released (unless they >>>are >>>> also needed for o-2, that is). >>>> >>>> Does it mean that the browser is just capable of having *one* >>>> multimedia session at the same time? Well, in SIP world this >>>typically >>>> means putting on-hold the previous call so, indeed, resources >>>would be >>>> released. >>>> >>>> But, why couldn't the browser send a just-audio offer somewhere >>>and a >>>> just-video offer to other destination at the same time? >>>> >>>> -- >>>> I=F1aki Baz Castillo >>>> > >>>> _______________________________________________ >>>> 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 >>> >>> >>>-- >>>Randell Jesup >>>randell-ietf@jesup.org >>>_______________________________________________ >>>rtcweb mailing list >>>rtcweb@ietf.org >>>https://www.ietf.org/mailman/listinfo/rtcweb From pravindran@sonusnet.com Sun Feb 26 18:21: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 789AB21F84B5 for ; Sun, 26 Feb 2012 18:21:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1 X-Spam-Level: * X-Spam-Status: No, score=1 tagged_above=-999 required=5 tests=[AWL=-3.261, BAYES_20=-0.74, GB_SUMOF=5, 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 irZiO59tnLPj for ; Sun, 26 Feb 2012 18:21:33 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 300AF21F84B2 for ; Sun, 26 Feb 2012 18:21:33 -0800 (PST) Received: from sonusmail06.sonusnet.com (sonusmail06.sonusnet.com [10.128.32.156]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q1R2MHmP006984; Sun, 26 Feb 2012 21:22:17 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail06.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 26 Feb 2012 21:21:28 -0500 Received: from INBA-HUB02.sonusnet.com ([10.70.51.87]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 27 Feb 2012 07:51:25 +0530 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, 27 Feb 2012 07:51:24 +0530 From: "Ravindran, Parthasarathi" To: "Ejzak, Richard P (Richard)" , Roman Shpount Thread-Topic: [rtcweb] Consensus call on JSEP/ROAP Thread-Index: AQHM5daOqyJlzHkk1UCHKJfTYUstZ5ZHSnCAgAA4QACAACbCgIAACJIAgAAEXACAAAYmAIADtmvg Date: Mon, 27 Feb 2012 02:21:23 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E04CD6A@inba-mail01.sonusnet.com> References: <6F428EFD2B8C2F49A2FB1317291A76C11355D49DF5@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <005BC7E2-88EE-4D8F-8AEA-4614D39A6DC6@employees.org> <6F428EFD2B8C2F49A2FB1317291A76C11355D4A12E@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <6F428EFD2B8C2F49A2FB1317291A76C11355D4A14E@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> In-Reply-To: <6F428EFD2B8C2F49A2FB1317291A76C11355D4A14E@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: multipart/alternative; boundary="_000_387F9047F55E8C42850AD6B3A7A03C6C0E04CD6Ainbamail01sonus_" MIME-Version: 1.0 X-OriginalArrivalTime: 27 Feb 2012 02:21:25.0214 (UTC) FILETIME=[811C27E0:01CCF4F6] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consensus call on JSEP/ROAP 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, 27 Feb 2012 02:21:39 -0000 --_000_387F9047F55E8C42850AD6B3A7A03C6C0E04CD6Ainbamail01sonus_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Richard, For your first mail on standard signaling, I would say that "Welcome to Web= RTC signaling". In fact, I had same expectation of standard signaling as yo= urs 6 months back, Please see WebRTC archive for more details. But, WebRTC = (wire) signaling protocol will be proprietary per website. The reason for t= his approach is that there is no need to interop between two different WebR= TC sites and same JS (signaling protocol) is executed in all the client wi= thin the single website. For example, www.partha.com= will have partha protocol and www.richard.com will= have Richard protocol wherein partha site and Richard site will never inte= rop with each other. Even if they decide to interop, it is upto Partha & Ri= chard to decide what is the choice of signaling protocol and no need of sta= ndard at this moment. We may wish to have later :). Hope this clarifies yo= ur doubt on signaling wire protocol. The aim of WebRTC signaling discussion is to verify whether JSEP (WebRTC si= gnaling protocol in API) defines the basic set of signaling protocol primit= ives like offer/answer which helps to develop any kind of proprietary/stand= ard protocol in the wire. So, it is perfectly valid to discuss proprietary = SIP callflow which are prevalent in the deployment in WebRTC mailing list a= nd it will be considered as one WebRTC application. AFAIK, media protocol= (SRTP, ICE) standard are followed in the normal standard fashion as differ= ent browsers (like Chrome, IE, Mozilla) and other WebRTC clients (gateways)= has to interop. As lot of standard SIP implementation exists, let us review JSEP in a way t= hat JSEP protocol develop JS application which helps to interop with standa= rd SIP but it is not the main motive of this group. Thanks Partha From: rtcweb-bounces@ietf.org [mailto:rtcwe= b-bounces@ietf.org] On Behalf Of Ejzak, Richard P (Richard) Sent: Wednesday, February 22, 2012 5:11 AM To: Roman Shpount Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Consensus call on JSEP/ROAP Hi Roman, You are correct that parallel forking is needed to model this case. I mean= t to distinguish between cases where the previous dialog is cleared immedia= tely upon receipt of a new dialog, compared to the case where multiple dial= ogs are maintained in parallel, and I messed up. Thanks. Richard ________________________________ From: Roman Shpount [mailto:roman@telurix.com] Sent: Tuesday, February 21, 2012 5:19 PM To: Ejzak, Richard P (Richard) Cc: Cary W FitzGerald; rtcweb@ietf.org Subject: Re: [rtcweb] Consensus call on JSEP/ROAP Hi Richard, I must apologize as well, since I know that this issue was discussed before= on the list and decision was made to support multiple provisional response= s. I am not sure there was a consensus call on it, but it looked like work = group decided to implement this in both ROAP and JSEP. I see your point abo= ut standards, but unfortunately real life is often different. You proposal in another thread is only an acceptable compromise if parallel= forking is supported. If parallel forking is supported, each new provision= al SDP can be treated as a new parallel fork and the previous media connect= ion can be discarded. _____________ Roman Shpount On Tue, Feb 21, 2012 at 6:02 PM, Ejzak, Richard P (Richard) > wrote: Hi Roman, If this issue has already been debated in the group, I must apologize. But= if standards had to accommodate every non-standard implementation in exist= ence then we wouldn't be able to accomplish much... I proposed in another thread that we model this kind of behavior with stand= ard SIP serial forking, which JSEP must be able to support. The SIP isn't = exactly the same, but the offer/answer sequence is. This allows implementa= tions to realize this flow in practice if necessary without encoding it in = our specs. Could this be an acceptable compromise? Richard ________________________________ From: Roman Shpount [mailto:roman@telurix.com] Sent: Tuesday, February 21, 2012 4:32 PM To: Cary W FitzGerald Cc: Ejzak, Richard P (Richard); rtcweb@ietf.org Subject: Re: [rtcweb] Consensus call on JSEP/ROAP Another issue is that real-life SIP deployments are often not RFC 3264 comp= laint. In particular it is not unusual to receive different SDP in provisio= nal and final INVITE response. This does not fit offer/answer model since i= t implies multiple answers to one offer with subsequent answers overwriting= previous ones. So, offer/answer compliance is insufficient even for the SI= P interop. _____________ Roman Shpount On Tue, Feb 21, 2012 at 3:13 PM, Cary W FitzGerald > wrote: This is partially inevitable. For WebRTC applications that interact with S= IP gateways, the WebRTC application can't signal anything that 3264 won't a= llow, since the gateway's side won't be able to deal with it. The original= architecture document http://tools.ietf.org/html/draft-ietf-rtcweb-overvie= w-02 proposes a RTC trapezoid and any well-behaved trapezoid needs to consi= der the SIP case and therefore 3264. There is another important case, which is when the trapezoid degenerates in= to a triangle. This is the case where the web server controls both sides o= f the conversation (e.g. connecting to an attendant at www.ftd.com without any intervening PBX/switch/traditional contact center).= Since there is no PSTN GW to contend with, it's not necessary to obey the= gateway's rules. In this case, the server presumably knows what it's doin= g, so it's probably a bug if it trips itself up. There is potentially a third case, which is where the trapezoid is maintain= ed, and the servers are communicating with some-protocol-not-SIP that doesn= 't need to abide by 3264 (which excludes H.323), but are not smart enough t= o coordinate media between themselves, but this doesn't seem very important= . I could be wrong about that, but I don't see the practical use case. Cary. On Feb 21, 2012, at 8:52 AM, Ejzak, Richard P (Richard) wrote: Hi All, I would like to point out that if you rephrase the question to ask "who pre= fers to base subsequent work on RFC 3264 semantics?", then you would need t= o combine positions 2 and 4, and you would get a vote of 28 (the position 3= votes) for a new semantic model (requiring significant new work on SDP) ag= ainst 21 (the sum of votes for positions 2 and 4) for RFC 3264 semantics. So while I do not object to using JSEP as a basis for further work, it seem= s that the group is far less certain about the on-the-wire semantics to be = associated with it. My preference is to focus on RFC 3264 semantics (notin= g that the low level of the API would still allow considerable flexibility = to support other signaling protocols). My key concern is to have clear rul= es (based on common semantics) for interworking media/transport negotiation= procedures between different on-the-wire protocols to avoid potential inte= rop problems. In particular, at this point in the discussion, I do not see the value of a= llowing multiple open OFFERs within a dialog (which have acknowledged probl= ems), multiple ANSWERs within a dialog, or PRANSWERs, none of which exist i= n RFC 3264. I propose that the group first decide whether to use JSEP as a basis for fu= rther work and in subsequent step(s) decide whether and how to go beyond RF= C 3264 semantics. I see this proposal as simply a clarification of the mea= ning of position 3. Richard Ejzak -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcwe= b-bounces@ietf.org] On Behalf Of Ted Hardie Sent: Tuesday, February 07, 2012 2:25 PM To: rtcweb@ietf.org Subject: [rtcweb] Consensus call on JSEP/ROAP During the interim meeting, the attendees discussed the JSEP and ROAP proposals. The chairs also asked the working group to consider whether they might be successfully merged. Because of audio difficulties, there is no recording available. The jabber logs contain a transcription of the discussion by Bernard Aboba and can be found here: http://www.ietf.org/jabber/logs/rtcweb/2012-01-31.html. At the end of the discussion, the chairs asked the attendees to indicate their preferences by standing for one of four positions, which wer= e listed prior to the question being called. The positions were: 1--Don't care whether ROAP or JSEP is the input document for further work in this area 2---Prefer ROAP be the input document for further work 3--Prefer JSEP be the input document for further work 4--Prefer to merge the docs, limiting JSEP to RFC 3264 offer/answer semanti= cs. The results were: 1=3D9 in room, none in jabber 2=3D11 in room, 2 in jabber 3=3D25 in room, 3 in jabber 4=3D8 in room, none in jabber. Because JSEP supports more than one model of negotiation, choosing 3 is a reversal from previous working group consensus to limit work to the offer/answer model. The chairs are now calling for consensus of the working group on this point. Working group participants who were not present at the interim, please review the input documents if you not have yet done so, and forward your comments to the list. All working group participants are asked to make their points on this topic by February 22nd, so that we have timely input prior to the document deadline for Paris. thanks, Ted Hardie for the Chairs _______________________________________________ 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 --_000_387F9047F55E8C42850AD6B3A7A03C6C0E04CD6Ainbamail01sonus_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Richard,

 <= /p>

For your first mail on st= andard signaling, I would say that “Welcome to WebRTC signaling”= ;. In fact, I had same expectation of standard signaling as yours 6 months back, Please see WebRTC archive for more details. But, WebRTC (wire= ) signaling protocol will be proprietary per website. The reason for this a= pproach is that there is no need to interop between two different WebRTC si= tes and same  JS (signaling protocol) is executed in all the client within the single website. For example, www.partha.com will have partha protocol and www.richard.com will have Richard protocol wherein partha site and Rich= ard site will never interop with each other. Even if they decide to interop= , it is upto Partha & Richard to decide what is the choice of signaling= protocol and no need of standard at this moment. We may wish to have later  J. Hope this clarifies your doubt on signaling wire protocol.

 <= /p>

The aim of WebRTC signali= ng discussion is to verify whether JSEP (WebRTC signaling protocol in API) = defines the basic set of signaling protocol primitives like offer/answer which helps to develop any kind of proprietary/standard proto= col in the wire. So, it is perfectly valid to discuss proprietary SIP callf= low which are prevalent in the deployment in WebRTC mailing list and it wil= l be considered as one WebRTC application.   AFAIK, media protocol (SRTP, ICE) standard are followed in the normal stan= dard fashion as different browsers (like Chrome, IE, Mozilla) and other Web= RTC clients (gateways) has to interop.

 <= /p>

As lot of standard SIP im= plementation exists, let us review JSEP in a way that JSEP protocol develop= JS application which helps to interop with standard SIP but it is not the main motive of this group.

 <= /p>

Thanks<= /p>

Partha<= /p>

 <= /p>

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ejzak, Richard P (Richard)
Sent: Wednesday, February 22, 2012 5:11 AM
To: Roman Shpount
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Consensus call on JSEP/ROAP<= /p>

 

Hi Roman,

You are correct that parallel = forking is needed to model this case.  I meant to distinguish between = cases where the previous dialog is cleared immediately upon receipt of a new dialog, compared to the case where multiple dialogs are maintaine= d in parallel, and I messed up.  Thanks.

 

Richard

 

From: Roman Sh= pount [mailto:roman@telurix.com]
Sent: Tuesday, February 21, 2012 5:19 PM
To: Ejzak, Richard P (Richard)
Cc: Cary W FitzGerald; rtcweb@iet= f.org
Subject: Re: [rtcweb] Consensus call on JSEP/ROAP<= /p>

 

Hi Richard,

I must apologize as well, since I know that this issue was discussed before= on the list and decision was made to support multiple provisional response= s. I am not sure there was a consensus call on it, but it looked like work = group decided to implement this in both ROAP and JSEP. I see your point about standards, but unfortunately= real life is often different.

You proposal in another thread is only an acceptable compromise if parallel= forking is supported. If parallel forking is supported, each new provision= al SDP can be treated as a new parallel fork and the previous media connect= ion can be discarded.
_____________
Roman Shpount

On Tue, Feb 21, 2012 at 6:02 PM, Ejzak, Richard P (R= ichard) <richard.ejz= ak@alcatel-lucent.com> wrote:

Hi Roman,

If this issue has already been debated in th= e group, I must apologize.  But if standards had to accommodate every non-standard implementation in existence then we wouldn’t be a= ble to accomplish much…

 

I proposed in another thread that we model t= his kind of behavior with standard SIP serial forking, which JSEP must be able to support.  The SIP isn’t exactly the same, = but the offer/answer sequence is.  This allows implementations to real= ize this flow in practice if necessary without encoding it in our specs.&nb= sp; Could this be an acceptable compromise?

 

Richard

 

From: Roman Shpount [mailto:= roman@telurix.com]
Sent: Tuesday, February 21, 2012 4:32 PM
To: Cary W FitzGerald
Cc: Ejzak, Richard P (Richard); rtcweb@ietf.org
Subject: Re: [rtcweb] Consensus call on JSEP/ROAP<= /p>

 

Another issue is that real-life SIP deployments are often not RFC 3264 c= omplaint. In particular it is not unusual to receive different SDP in provi= sional and final INVITE response. This does not fit offer/answer model since it implies multiple answers to one o= ffer with subsequent answers overwriting previous ones. So, offer/answer co= mpliance is insufficient even for the SIP interop.
_____________
Roman Shpount

On Tue, Feb 21, 2012 at 3:13 PM, Cary W FitzGerald <caryfitz@employees.org= > wrote:

This is partially inevitable.  For WebRTC applications that i= nteract with SIP gateways, the WebRTC application can't signal anything tha= t 3264 won't allow, since the gateway's side won't be able to deal with it.  The original architecture document&nb= sp;http://tools.ietf.org/html/draft-ietf-rtcweb-overview-02=  proposes a RTC trapezoid and any well-behaved trapezoid needs to consider the SIP case and therefore 3264.

 

There is another important case, which is when the trapezoid degen= erates into a triangle.  This is the case where the web server control= s both sides of the conversation (e.g. connecting to an attendant at www.ft= d.com without any intervening PBX/switch/traditional contact center). &= nbsp;Since there is no PSTN GW to contend with, it's not necessary to obey = the gateway's rules.  In this case, the server presumably knows what it's doing, so it's probably a bug if it trips itsel= f up.

 

There is potentially a third case, which is where the trapezoid is= maintained, and the servers are communicating with some-protocol-not-SIP t= hat doesn't need to abide by 3264 (which excludes H.323), but are not smart enough to coordinate media between them= selves, but this doesn't seem very important.  I could be wrong about = that, but I don't see the practical use case.

 

Cary.

 

On Feb 21, 2012, at 8:52 AM, Ejzak, Richard P (Richard) wrote:

 

Hi All,
I would like to point out that if you rephrase the question to ask "wh= o prefers to base subsequent work on RFC 3264 semantics?", then you wo= uld need to combine positions 2 and 4, and you would get a vote of 28 (the = position 3 votes) for a new semantic model (requiring significant new work on SDP) against 21 (the sum of votes for p= ositions 2 and 4) for RFC 3264 semantics.

So while I do not object to using JSEP as a basis for further work, it seem= s that the group is far less certain about the on-the-wire semantics to be = associated with it.  My preference is to focus on RFC 3264 semantics (= noting that the low level of the API would still allow considerable flexibility to support other signaling prot= ocols).  My key concern is to have clear rules (based on common semant= ics) for interworking media/transport negotiation procedures between differ= ent on-the-wire protocols to avoid potential interop problems.  

In particular, at this point in the discussion, I do not see the value of a= llowing multiple open OFFERs within a dialog (which have acknowledged probl= ems), multiple ANSWERs within a dialog, or PRANSWERs, none of which exist i= n RFC 3264.

I propose that the group first decide whether to use JSEP as a basis for fu= rther work and in subsequent step(s) decide whether and how to go beyond RF= C 3264 semantics.  I see this proposal as simply a clarification of th= e meaning of position 3.

Richard Ejzak

-----Original Message-----
From: rtcweb-b= ounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ted Hardie
Sent: Tuesday, February 07, 2012 2:25 PM
To: rtcweb@ietf.org
Subject: [rtcweb] Consensus call on JSEP/ROAP

During the interim meeting, the attendees discussed the JSEP and ROAP
proposals.  The chairs also asked the working group to consider
whether they might be successfully merged.  Because of audio difficult= ies,
there is no recording available.  The jabber logs contain
a transcription of the discussion by Bernard Aboba and can be found
here: http://www.ietf.org/jabber/logs/rtcweb/2012-01-31.html.

At the end of the discussion, the chairs asked the attendees to
indicate their preferences by standing for one of four positions, which wer= e
listed prior to the question being called.  The positions were:

1--Don't care whether ROAP or JSEP is the input document for further
work in this area

2---Prefer ROAP be the input document for further work

3--Prefer JSEP be the input document for further work

4--Prefer to merge the docs, limiting JSEP to RFC 3264 offer/answer semanti= cs.

The results were: 1=3D9 in room, none in jabber
            &nb= sp;            =    2=3D11 in room, 2 in jabber
            &nb= sp;            =    3=3D25 in room, 3 in jabber
            &nb= sp;            =    4=3D8 in room, none in jabber.

Because JSEP supports more than one model of negotiation, choosing 3
is a reversal  from previous working group consensus to limit work to<= br> the offer/answer model.

The chairs are now calling for consensus of the working group on this
point.  Working group participants who were not present at the interim= ,
please review the input documents if you not have yet done so, and
forward your comments to the list.  All working group participants are=
asked to make
their points on this topic by February 22nd, so that we have timely
input prior to the document deadline for Paris.

thanks,

Ted Hardie for the Chairs
_______________________________________________
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

 

 

--_000_387F9047F55E8C42850AD6B3A7A03C6C0E04CD6Ainbamail01sonus_-- From christer.holmberg@ericsson.com Mon Feb 27 02:37: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 618BA21F868A for ; Mon, 27 Feb 2012 02:37:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.892 X-Spam-Level: X-Spam-Status: No, score=-9.892 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, J_CHICKENPOX_65=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 5AhzIjbUOyHF for ; Mon, 27 Feb 2012 02:37:47 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id CB0F621F8686 for ; Mon, 27 Feb 2012 02:37:37 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-93-4f4b5ce0de72 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 15.4F.01970.0EC5B4F4; Mon, 27 Feb 2012 11:37:31 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.31]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Mon, 27 Feb 2012 11:36:43 +0100 From: Christer Holmberg To: "Ravindran, Parthasarathi" , "Khan, Sohel" , "Ejzak, Richard P (Richard)" , "rtcweb@ietf.org" , "public-webrtc@w3.org" Date: Mon, 27 Feb 2012 11:36:02 +0100 Thread-Topic: [rtcweb] JSEP-02: New offer and answer to previous offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case] Thread-Index: AQHM8AqE+28vByK84kKxG08H/gll95ZF3BIAgAAASYCAAASXgIAAGTuAgADuMECAAH0N0IAAZRbggAAhZzCAAFDIgIAAcX8AgAdZ23CAAI6u0A== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3F3A4F68@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C3D31BA37@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C3D31BA3A@ESESSCMS0356.eemea.ericsson.se> <4F42C2C7.3060802@jesup.org> <387F9047F55E8C42850AD6B3A7A03C6C0E040FFE@inba-mail01.sonusnet.com> <6F428EFD2B8C2F49A2FB1317291A76C11355D49C4E@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <387F9047F55E8C42850AD6B3A7A03C6C0E0412EB@inba-mail01.sonusnet.com> <6F428EFD2B8C2F49A2FB1317291A76C11355D4A115@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <387F9047F55E8C42850AD6B3A7A03C6C0E041386@inba-mail01.sonusnet.com> <837E772D16C77141BFA5FEC3F30487FF525CA77C@PACDCEXMB02.cable.comcast.com> <387F9047F55E8C42850AD6B3A7A03C6C0E04AD34@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E04AD34@inba-mail01.sonusnet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case] 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, 27 Feb 2012 10:37:49 -0000 Hi, I guess the UPDATE is something you send just as an "optimization" (in orde= r to avoid media to be transmitted by one remote party), but it's not somet= hing you suggest to be mandated from an API perspective? Regards, Christer -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Ravindran, Parthasarathi Sent: 27. helmikuuta 2012 4:15 To: Khan, Sohel; Ejzak, Richard P (Richard); rtcweb@ietf.org; public-webrtc= @w3.org Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous offer [was:= JSEP-02: SDP_PRANSWER and FEDEX use-case] Hi Richard/Sohel, I attached updated 3 callflows with this mail. 1) Single offer and multiple answer 2) SIP Serial forking 3) SIP Parallel forking I have add the comment "Handling of Reliable response PRACK and 200 is not = shown for simplicity" to indicate about Standard SIP callflow. Please let m= e know your comment on this. Thanks Partha >-----Original Message----- >From: Khan, Sohel [mailto:Sohel_Khan@cable.comcast.com] >Sent: Wednesday, February 22, 2012 8:49 PM >To: Ravindran, Parthasarathi; Ejzak, Richard P (Richard); >rtcweb@ietf.org; public-webrtc@w3.org >Subject: RE: [rtcweb] JSEP-02: New offer and answer to previous offer >[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] > >Partha, > >If possible, please minimize the use of PRACK in the call flow. We >would like to have call flows simple and less chatty. > >Sohel > >-----Original Message----- >From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] >Sent: Tuesday, February 21, 2012 10:32 PM >To: Ejzak, Richard P (Richard); rtcweb@ietf.org; public-webrtc@w3.org >Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous offer >[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] > >Hi Richard, > >Thanks for your comments. I have put the focus on the offer/answer >exchange between OffererJS and OffererUA in the callflow and assumed >18x as reliable. I'm bit afraid to write too much details about SIP in >this forum (see RTCWeb archive for more details) :-) > >I'll update the callflow with PRACK & 200. Out of the 3 requested >usecases, I have provided 1 and 3 with this assumption. I'll send 2nd >usecase of serial forking with UPDATE and updated standard callflow for >1st & 3rd usecase ASAP. > >My intention is not to violate standard but I have provided the >deployed >(real-time) usecases as Cullen requested and also mentioned in the same >mail how to make those callflow standard compliance. For your concern >on signaling standard deviation discussion within WebRTC, I'll write >the separate mail. > >Thanks >Partha > >>-----Original Message----- >>From: Ejzak, Richard P (Richard) [mailto:richard.ejzak@alcatel- >>lucent.com] >>Sent: Wednesday, February 22, 2012 4:15 AM >>To: Ravindran, Parthasarathi; rtcweb@ietf.org; public-webrtc@w3.org >>Subject: RE: [rtcweb] JSEP-02: New offer and answer to previous offer >>[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] >> >>Hi Partha, >>Thanks for the call flows and explanations. >> >>For all of your flows, it would really help if any deviation from RFC >>3261 or RFC 3264 is clearly noted in your flows. Further, it would >>help to be clear when you assume reliable or unreliable provisionals, >>since that makes a big difference. You appear to usually assume >>reliable provisionals, but I want to be sure. >> >>It would also help to identify the purpose of some key operations in >>each flow when not strictly for protocol conformance. For example, >>setting some flows to "inactive" is used to avoid having multiple >>media flows when parallel forking, but this is an application choice >>rather than a protocol necessity. >> >>You state that your earlier flow violates RFC 3261, and in an earlier >>posting you insist that it should be supported because some >>implementations behave that way. I have a real problem with this. >>Standards are meant to help in avoiding exactly this kind of situation >>and I don't think that non-standard behavior should be condoned by >>rtcweb. If there is good reason to support this kind of flow then it >>should be brought to the appropriate working group for consideration >>(not rtcweb). An endpoint could achieve similar behavior by mimicking >>standard serial forking procedures (which is what I thought you >>intended but you forgot to include the interim final responses or >>byes). Why not just use a sequence of UPDATEs and avoid these hassles? >> >>The three use cases I had in mind were: >> >>1) mimicking standard serial forking from a single endpoint to realize >>the equivalent of multiple ANSWERs to a single OFFER (although >>separate OFFER/ANSWER transactions using UPDATE would be cleaner) >>2) standard serial forking (with optional UPDATEs) >>3) standard parallel forking (with optional UPDATEs) >> >>Do we really need anything other than 2) and 3)? >> >>Richard >> >>-----Original Message----- >>From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] >>Sent: Tuesday, February 21, 2012 2:51 PM >>To: Ejzak, Richard P (Richard); rtcweb@ietf.org; public-webrtc@w3.org; >>Randell Jesup >>Subject: RE: [rtcweb] JSEP-02: New offer and answer to previous offer >>[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] >> >>Hi all, >> >>Till now, I'm writing the callflow with the assumption of browser as >>RTP Endpoint. Two JSEP example call flow are attached: >> >> 1) Two 180 with SDP (answer) and second 180's dialog comes up with >2xx >>with SDP >> 2) Two 180 with SDP (answer) and first 180's dialog comes up >>with 2xx with SDP >> >>The above callflows are not the only way to solve the problem but it >>is one of the way to solve this callflow. The intention of these >>callflows are to indicate that multiple answers support in JSEP >>facilities for designing SIP parallel forking kind of services. The >>exact intention is as per >>http://www.ietf.org/mail-archive/web/rtcweb/current/msg03455.html >>and as follows: >> >>1) allow a setRemoteDesc(SDP_ANSWER) to follow a >>setRemoteDesc(SDP_ANSWER) >>2) document that in this case (multiple 2xx), the JS is responsible >>for sending BYE to the previous answerer. >> >>Please let me know your comments on the callflow. >> >>Hi Richard, >> >>Thanks for your clarification in the below mail. Please read inline >>for more comments >> >>Thanks >>Partha >> >>>-----Original Message----- >>>From: Ejzak, Richard P (Richard) [mailto:richard.ejzak@alcatel- >>>lucent.com] >>>Sent: Tuesday, February 21, 2012 8:05 PM >>>To: Ravindran, Parthasarathi; rtcweb@ietf.org; public-webrtc@w3.org >>>Subject: RE: [rtcweb] JSEP-02: New offer and answer to previous offer >>>[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] >>> >>>Hi Partha, >>>Regarding my earlier email (this earlier email was not distributed on >>>the webrtc list), I do not dispute that forking must be supported by >>>all SIP endpoints. Let me rephrase my earlier questions in light of >>>your latest call flow. >>> >>>Looking at your call flow, I see that you treat the case of multiple >>>answers from the same endpoint as a serial forking case (or do I >>>misunderstand your intent?). >> >> I agree that this callflow is allowed in JSEP and it is a >>violation of RFC 3261 and not RFC 3264. I explained in detail why this >>callflow shall be allowed in http://www.ietf.org/mail- >>archive/web/rtcweb/current/msg03478.html >> >> How do you determine that this is a >>>special type of serial forking and not a parallel forking case? >> >> I won't determine it. I will just update based on the last >>active answer. >> >> We have >>>at least three use cases for multiple ANSWER and it would be helpful >>>to see how they can be handled and distinguished in SIP signaling. >>> >> Please mentioned the three of them. I'll provide the callflow >>for the same >> >>>Also, PRANSWER as currently defined seems to have no analog in SIP. >>>Is this also your understanding? >> We have the common understanding here. I'm requesting to >>remove PR_ANSWER state as it complicates JS Offer/Answer FSM still >>more >(See: >>http://www.ietf.org/mail-archive/web/rtcweb/current/msg03489.html). >> >> >>> >>>I don't understand your statement that "It is possible to implement >>>parallel forking by keeping only one answer active in the offerer >>>side at the given time". It would appear that an implementation of >>>parallel forking would need to keep the last answer from each dialog >active. >>>Please explain. >>> >> Hope the callflow clarifies >> >>>I look forward to your next call flow. >>> >>>Richard >>> >>>-----Original Message----- >>>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >>>Behalf Of Ravindran, Parthasarathi >>>Sent: Tuesday, February 21, 2012 12:58 AM >>>To: Randell Jesup; rtcweb@ietf.org; public-webrtc@w3.org >>>Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous offer >>>[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] >>> >>>Randell, >>> >>>It is possible to implement parallel forking by keeping only one >>>answer active in the offerer side at the given time. I attached one >>>of the example "18x with SDP and 2xx with different SDP" for your >>>reference which will map to serial forking. Please let me know your >>>concern about ICE interaction concern here. >>> >>>I'll send multiple 18x with SDP and one 2xx with SDP response JSEP >>>example using UPDATE O/A mechanism ASAP for clarity on parallel >>>forking >>>(assumption: multiple answer for single offer is supported in JSEP). >>> >>>Thanks >>>Partha >>> >>>>-----Original Message----- >>>>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >>>>Behalf Of Randell Jesup >>>>Sent: Tuesday, February 21, 2012 3:32 AM >>>>To: rtcweb@ietf.org; public-webrtc@w3.org >>>>Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous >>>>offer >>>>[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] >>>> >>>>On 2/20/2012 3:31 PM, Roman Shpount wrote: >>>>> Not to beat this horse to death, but why is it "suggested not to >>>>> have parallel forking"? WebRTC intorduces additional restrictions >>>>> on RTP stream (remote media sources and SSRCs are known in >>>>> advance) that make parallel forking implementation trivial. Only >>>>> thing that is missing is some way to clone the PeerConnection in the = API. >>>> >>>>Right; parallel forking has uses. >>>> >>>>We've talked about this, but not for a while. One way to implement >>>>it would be to on each forked answer clone the state of the >>>>PeerConnection as it was with any previous answer removed. However, >>>>I'm concerned about how this will interact with the ICE, etc stuff. >>>>Someone want to throw out a suggestion? Cullen, Justin - how >>>>*should*/*could* forking work within JSEP? >>>> >>>> >>>>Aside on uses of forking: >>>>I can see some additional interesting uses for parallel forking, >>>>especially in non-phone-like usecases (games among others). The >>>>server (or another participant) could hold open an OFFER in order to >>>>forward it to any potential new partners. This might apply to a >>>>conference call as well if there's a peer-2-peer aspect (mesh, >>>>partial-mesh, etc) >>>to it. >>>> >>>>Think in a game or 2nd-life-type-sim, where you're automatically in >>>>a voice chat with anyone within hearing range, and those voice chats >>>>are done p2p by forking each player's original offer to the server, >>>>and forwarding it (forking it) to the new user, who would answer and >>>>they'd be in a call. >>>> >>>>If you wanted to get really fancy, you could even do some of the >>>>negotiation in the server and rephrase each offer as an answer to >>>>the other side, leading to a 1/2-RTT-to-the-server setup time >>>>(more-or- >>>less: >>>> >>>>player 1 server player 2 >>>>------------------------------------------------------------ >>>>| | | >>>>|--> Offer 1 ---------------->| | >>>>| |<---------- Offer 2 <----| >>>>| | | >>>>... >>>> Server decides they should talk >>>>| | | >>>>|<-- Answer(Offer 2) <--------|-----> Answer(Offer 1)-->| >>>>|<------------------------- media --------------------->| >>>> >>>>Even if this is initiated by a player, there are equivalent graphs >>>>that use 1/2 RTT (through the server to other player) to set up >>channels. >>>> >>>>I should note however that ICE overhead may well swamp this fancy >>>>setup and it may be over-reaching, but each 1/2 RTT removed is >>>>significant, so there may be uses. >>>> >>>>> _____________ >>>>> Roman Shpount >>>>> >>>>> >>>>> On Mon, Feb 20, 2012 at 3:14 PM, Christer Holmberg >>>>> >>>> > >>>>> wrote: >>>>> >>>>> >>>>> Hi, >>>>> >>>>> Just to clarify: the new offer is for the same "session" as the >>>>> previous offer, and is supposed to replace the previous offer. >>>>> >>>>> The browser can of course send a just-audio offer somewhere, >>>>> and >>>a >>>>> just-video offer somewhere else, but would those even be >>>>associated >>>>> with the same PeerConnection? I thought we wanted only one >>>>> offer/answer, which is the reason it has been suggested e.g. >>>>> not >>>>to >>>>> support paralell forking in the browser. >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> ________________________________________ >>>>> From: I=F1aki Baz Castillo [ibc@aliax.net ] >>>>> Sent: Monday, February 20, 2012 10:13 PM >>>>> To: Christer Holmberg >>>>> Cc: Justin Uberti; rtcweb@ietf.org ; >>>>> public-webrtc@w3.org >>>>> Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous >>>>> offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case] >>>>> >>>>> 2012/2/20 Christer Holmberg >>>> >: >>>>> > Q1. When the JS app requests the new offer (o-2), I assume >>all >>>>> resources etc associated with o-1 will be released (unless >>>>> they >>>>are >>>>> also needed for o-2, that is). >>>>> >>>>> Does it mean that the browser is just capable of having *one* >>>>> multimedia session at the same time? Well, in SIP world this >>>>typically >>>>> means putting on-hold the previous call so, indeed, resources >>>>would be >>>>> released. >>>>> >>>>> But, why couldn't the browser send a just-audio offer >>>>> somewhere >>>>and a >>>>> just-video offer to other destination at the same time? >>>>> >>>>> -- >>>>> I=F1aki Baz Castillo >>>>> > >>>>> _______________________________________________ >>>>> 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 >>>> >>>> >>>>-- >>>>Randell Jesup >>>>randell-ietf@jesup.org >>>>_______________________________________________ >>>>rtcweb mailing list >>>>rtcweb@ietf.org >>>>https://www.ietf.org/mailman/listinfo/rtcweb From pravindran@sonusnet.com Mon Feb 27 03:28: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 9891921F86B7 for ; Mon, 27 Feb 2012 03:28:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.235 X-Spam-Level: X-Spam-Status: No, score=-2.235 tagged_above=-999 required=5 tests=[AWL=-0.236, BAYES_00=-2.599, J_CHICKENPOX_65=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 q2HQd1BVfa1q for ; Mon, 27 Feb 2012 03:28:05 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE2721F86B5 for ; Mon, 27 Feb 2012 03:28:04 -0800 (PST) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q1RBSkKC006346; Mon, 27 Feb 2012 06:28:46 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 27 Feb 2012 06:27:57 -0500 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 27 Feb 2012 16:57:53 +0530 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; Mon, 27 Feb 2012 16:57:53 +0530 From: "Ravindran, Parthasarathi" To: Christer Holmberg , "Khan, Sohel" , "Ejzak, Richard P (Richard)" , "rtcweb@ietf.org" , "public-webrtc@w3.org" Thread-Topic: [rtcweb] JSEP-02: New offer and answer to previous offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case] Thread-Index: AQHM8AqE+28vByK84kKxG08H/gll95ZF3BIAgAAASYCAAASXgIAAGTuAgADuMECAAH0N0IAAZRbggAAhZzCAAFDIgIAAcX8AgAdZ23CAAI6u0IAAC+Gw Date: Mon, 27 Feb 2012 11:27:53 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E04DF05@inba-mail01.sonusnet.com> References: <7F2072F1E0DE894DA4B517B93C6A05852C3D31BA37@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C3D31BA3A@ESESSCMS0356.eemea.ericsson.se> <4F42C2C7.3060802@jesup.org> <387F9047F55E8C42850AD6B3A7A03C6C0E040FFE@inba-mail01.sonusnet.com> <6F428EFD2B8C2F49A2FB1317291A76C11355D49C4E@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <387F9047F55E8C42850AD6B3A7A03C6C0E0412EB@inba-mail01.sonusnet.com> <6F428EFD2B8C2F49A2FB1317291A76C11355D4A115@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <387F9047F55E8C42850AD6B3A7A03C6C0E041386@inba-mail01.sonusnet.com> <837E772D16C77141BFA5FEC3F30487FF525CA77C@PACDCEXMB02.cable.comcast.com> <387F9047F55E8C42850AD6B3A7A03C6C0E04AD34@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C3F3A4F68@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3F3A4F68@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.67] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 27 Feb 2012 11:27:53.0696 (UTC) FILETIME=[D8917600:01CCF542] Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case] 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, 27 Feb 2012 11:28:06 -0000 Hi Christer, You are right that UPDATE is just for optimization and there is nothing man= dated in API.=20 Thanks Partha >-----Original Message----- >From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >Sent: Monday, February 27, 2012 4:06 PM >To: Ravindran, Parthasarathi; Khan, Sohel; Ejzak, Richard P (Richard); >rtcweb@ietf.org; public-webrtc@w3.org >Subject: RE: [rtcweb] JSEP-02: New offer and answer to previous offer >[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] > > >Hi, > >I guess the UPDATE is something you send just as an "optimization" (in >order to avoid media to be transmitted by one remote party), but it's >not something you suggest to be mandated from an API perspective? > >Regards, > >Christer > > >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of Ravindran, Parthasarathi >Sent: 27. helmikuuta 2012 4:15 >To: Khan, Sohel; Ejzak, Richard P (Richard); rtcweb@ietf.org; public- >webrtc@w3.org >Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous offer >[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] > >Hi Richard/Sohel, > >I attached updated 3 callflows with this mail. > >1) Single offer and multiple answer >2) SIP Serial forking >3) SIP Parallel forking > >I have add the comment "Handling of Reliable response PRACK and 200 is >not shown for simplicity" to indicate about Standard SIP callflow. >Please let me know your comment on this. > >Thanks >Partha > >>-----Original Message----- >>From: Khan, Sohel [mailto:Sohel_Khan@cable.comcast.com] >>Sent: Wednesday, February 22, 2012 8:49 PM >>To: Ravindran, Parthasarathi; Ejzak, Richard P (Richard); >>rtcweb@ietf.org; public-webrtc@w3.org >>Subject: RE: [rtcweb] JSEP-02: New offer and answer to previous offer >>[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] >> >>Partha, >> >>If possible, please minimize the use of PRACK in the call flow. We >>would like to have call flows simple and less chatty. >> >>Sohel >> >>-----Original Message----- >>From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] >>Sent: Tuesday, February 21, 2012 10:32 PM >>To: Ejzak, Richard P (Richard); rtcweb@ietf.org; public-webrtc@w3.org >>Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous offer >>[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] >> >>Hi Richard, >> >>Thanks for your comments. I have put the focus on the offer/answer >>exchange between OffererJS and OffererUA in the callflow and assumed >>18x as reliable. I'm bit afraid to write too much details about SIP in >>this forum (see RTCWeb archive for more details) :-) >> >>I'll update the callflow with PRACK & 200. Out of the 3 requested >>usecases, I have provided 1 and 3 with this assumption. I'll send 2nd >>usecase of serial forking with UPDATE and updated standard callflow for >>1st & 3rd usecase ASAP. >> >>My intention is not to violate standard but I have provided the >>deployed >>(real-time) usecases as Cullen requested and also mentioned in the same >>mail how to make those callflow standard compliance. For your concern >>on signaling standard deviation discussion within WebRTC, I'll write >>the separate mail. >> >>Thanks >>Partha >> >>>-----Original Message----- >>>From: Ejzak, Richard P (Richard) [mailto:richard.ejzak@alcatel- >>>lucent.com] >>>Sent: Wednesday, February 22, 2012 4:15 AM >>>To: Ravindran, Parthasarathi; rtcweb@ietf.org; public-webrtc@w3.org >>>Subject: RE: [rtcweb] JSEP-02: New offer and answer to previous offer >>>[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] >>> >>>Hi Partha, >>>Thanks for the call flows and explanations. >>> >>>For all of your flows, it would really help if any deviation from RFC >>>3261 or RFC 3264 is clearly noted in your flows. Further, it would >>>help to be clear when you assume reliable or unreliable provisionals, >>>since that makes a big difference. You appear to usually assume >>>reliable provisionals, but I want to be sure. >>> >>>It would also help to identify the purpose of some key operations in >>>each flow when not strictly for protocol conformance. For example, >>>setting some flows to "inactive" is used to avoid having multiple >>>media flows when parallel forking, but this is an application choice >>>rather than a protocol necessity. >>> >>>You state that your earlier flow violates RFC 3261, and in an earlier >>>posting you insist that it should be supported because some >>>implementations behave that way. I have a real problem with this. >>>Standards are meant to help in avoiding exactly this kind of situation >>>and I don't think that non-standard behavior should be condoned by >>>rtcweb. If there is good reason to support this kind of flow then it >>>should be brought to the appropriate working group for consideration >>>(not rtcweb). An endpoint could achieve similar behavior by mimicking >>>standard serial forking procedures (which is what I thought you >>>intended but you forgot to include the interim final responses or >>>byes). Why not just use a sequence of UPDATEs and avoid these >hassles? >>> >>>The three use cases I had in mind were: >>> >>>1) mimicking standard serial forking from a single endpoint to realize >>>the equivalent of multiple ANSWERs to a single OFFER (although >>>separate OFFER/ANSWER transactions using UPDATE would be cleaner) >>>2) standard serial forking (with optional UPDATEs) >>>3) standard parallel forking (with optional UPDATEs) >>> >>>Do we really need anything other than 2) and 3)? >>> >>>Richard >>> >>>-----Original Message----- >>>From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] >>>Sent: Tuesday, February 21, 2012 2:51 PM >>>To: Ejzak, Richard P (Richard); rtcweb@ietf.org; public-webrtc@w3.org; >>>Randell Jesup >>>Subject: RE: [rtcweb] JSEP-02: New offer and answer to previous offer >>>[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] >>> >>>Hi all, >>> >>>Till now, I'm writing the callflow with the assumption of browser as >>>RTP Endpoint. Two JSEP example call flow are attached: >>> >>> 1) Two 180 with SDP (answer) and second 180's dialog comes up >>> with >>2xx >>>with SDP >>> 2) Two 180 with SDP (answer) and first 180's dialog comes up >>>with 2xx with SDP >>> >>>The above callflows are not the only way to solve the problem but it >>>is one of the way to solve this callflow. The intention of these >>>callflows are to indicate that multiple answers support in JSEP >>>facilities for designing SIP parallel forking kind of services. The >>>exact intention is as per >>>http://www.ietf.org/mail-archive/web/rtcweb/current/msg03455.html >>>and as follows: >>> >>>1) allow a setRemoteDesc(SDP_ANSWER) to follow a >>>setRemoteDesc(SDP_ANSWER) >>>2) document that in this case (multiple 2xx), the JS is responsible >>>for sending BYE to the previous answerer. >>> >>>Please let me know your comments on the callflow. >>> >>>Hi Richard, >>> >>>Thanks for your clarification in the below mail. Please read inline >>>for more comments >>> >>>Thanks >>>Partha >>> >>>>-----Original Message----- >>>>From: Ejzak, Richard P (Richard) [mailto:richard.ejzak@alcatel- >>>>lucent.com] >>>>Sent: Tuesday, February 21, 2012 8:05 PM >>>>To: Ravindran, Parthasarathi; rtcweb@ietf.org; public-webrtc@w3.org >>>>Subject: RE: [rtcweb] JSEP-02: New offer and answer to previous offer >>>>[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] >>>> >>>>Hi Partha, >>>>Regarding my earlier email (this earlier email was not distributed on >>>>the webrtc list), I do not dispute that forking must be supported by >>>>all SIP endpoints. Let me rephrase my earlier questions in light of >>>>your latest call flow. >>>> >>>>Looking at your call flow, I see that you treat the case of multiple >>>>answers from the same endpoint as a serial forking case (or do I >>>>misunderstand your intent?). >>> >>> I agree that this callflow is allowed in JSEP and it is a >>>violation of RFC 3261 and not RFC 3264. I explained in detail why this >>>callflow shall be allowed in http://www.ietf.org/mail- >>>archive/web/rtcweb/current/msg03478.html >>> >>> How do you determine that this is a >>>>special type of serial forking and not a parallel forking case? >>> >>> I won't determine it. I will just update based on the last >>>active answer. >>> >>> We have >>>>at least three use cases for multiple ANSWER and it would be helpful >>>>to see how they can be handled and distinguished in SIP signaling. >>>> >>> Please mentioned the three of them. I'll provide the callflow >>>for the same >>> >>>>Also, PRANSWER as currently defined seems to have no analog in SIP. >>>>Is this also your understanding? >>> We have the common understanding here. I'm requesting to >>>remove PR_ANSWER state as it complicates JS Offer/Answer FSM still >>>more >>(See: >>>http://www.ietf.org/mail-archive/web/rtcweb/current/msg03489.html). >>> >>> >>>> >>>>I don't understand your statement that "It is possible to implement >>>>parallel forking by keeping only one answer active in the offerer >>>>side at the given time". It would appear that an implementation of >>>>parallel forking would need to keep the last answer from each dialog >>active. >>>>Please explain. >>>> >>> Hope the callflow clarifies >>> >>>>I look forward to your next call flow. >>>> >>>>Richard >>>> >>>>-----Original Message----- >>>>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >>>>Behalf Of Ravindran, Parthasarathi >>>>Sent: Tuesday, February 21, 2012 12:58 AM >>>>To: Randell Jesup; rtcweb@ietf.org; public-webrtc@w3.org >>>>Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous offer >>>>[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] >>>> >>>>Randell, >>>> >>>>It is possible to implement parallel forking by keeping only one >>>>answer active in the offerer side at the given time. I attached one >>>>of the example "18x with SDP and 2xx with different SDP" for your >>>>reference which will map to serial forking. Please let me know your >>>>concern about ICE interaction concern here. >>>> >>>>I'll send multiple 18x with SDP and one 2xx with SDP response JSEP >>>>example using UPDATE O/A mechanism ASAP for clarity on parallel >>>>forking >>>>(assumption: multiple answer for single offer is supported in JSEP). >>>> >>>>Thanks >>>>Partha >>>> >>>>>-----Original Message----- >>>>>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >>>>>Behalf Of Randell Jesup >>>>>Sent: Tuesday, February 21, 2012 3:32 AM >>>>>To: rtcweb@ietf.org; public-webrtc@w3.org >>>>>Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous >>>>>offer >>>>>[was: JSEP-02: SDP_PRANSWER and FEDEX use-case] >>>>> >>>>>On 2/20/2012 3:31 PM, Roman Shpount wrote: >>>>>> Not to beat this horse to death, but why is it "suggested not to >>>>>> have parallel forking"? WebRTC intorduces additional restrictions >>>>>> on RTP stream (remote media sources and SSRCs are known in >>>>>> advance) that make parallel forking implementation trivial. Only >>>>>> thing that is missing is some way to clone the PeerConnection in >the API. >>>>> >>>>>Right; parallel forking has uses. >>>>> >>>>>We've talked about this, but not for a while. One way to implement >>>>>it would be to on each forked answer clone the state of the >>>>>PeerConnection as it was with any previous answer removed. However, >>>>>I'm concerned about how this will interact with the ICE, etc stuff. >>>>>Someone want to throw out a suggestion? Cullen, Justin - how >>>>>*should*/*could* forking work within JSEP? >>>>> >>>>> >>>>>Aside on uses of forking: >>>>>I can see some additional interesting uses for parallel forking, >>>>>especially in non-phone-like usecases (games among others). The >>>>>server (or another participant) could hold open an OFFER in order to >>>>>forward it to any potential new partners. This might apply to a >>>>>conference call as well if there's a peer-2-peer aspect (mesh, >>>>>partial-mesh, etc) >>>>to it. >>>>> >>>>>Think in a game or 2nd-life-type-sim, where you're automatically in >>>>>a voice chat with anyone within hearing range, and those voice chats >>>>>are done p2p by forking each player's original offer to the server, >>>>>and forwarding it (forking it) to the new user, who would answer and >>>>>they'd be in a call. >>>>> >>>>>If you wanted to get really fancy, you could even do some of the >>>>>negotiation in the server and rephrase each offer as an answer to >>>>>the other side, leading to a 1/2-RTT-to-the-server setup time >>>>>(more-or- >>>>less: >>>>> >>>>>player 1 server player 2 >>>>>------------------------------------------------------------ >>>>>| | | >>>>>|--> Offer 1 ---------------->| | >>>>>| |<---------- Offer 2 <----| >>>>>| | | >>>>>... >>>>> Server decides they should talk >>>>>| | | >>>>>|<-- Answer(Offer 2) <--------|-----> Answer(Offer 1)-->| >>>>>|<------------------------- media --------------------->| >>>>> >>>>>Even if this is initiated by a player, there are equivalent graphs >>>>>that use 1/2 RTT (through the server to other player) to set up >>>channels. >>>>> >>>>>I should note however that ICE overhead may well swamp this fancy >>>>>setup and it may be over-reaching, but each 1/2 RTT removed is >>>>>significant, so there may be uses. >>>>> >>>>>> _____________ >>>>>> Roman Shpount >>>>>> >>>>>> >>>>>> On Mon, Feb 20, 2012 at 3:14 PM, Christer Holmberg >>>>>> >>>>> > >>>>>> wrote: >>>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> Just to clarify: the new offer is for the same "session" as >the >>>>>> previous offer, and is supposed to replace the previous offer. >>>>>> >>>>>> The browser can of course send a just-audio offer somewhere, >>>>>> and >>>>a >>>>>> just-video offer somewhere else, but would those even be >>>>>associated >>>>>> with the same PeerConnection? I thought we wanted only one >>>>>> offer/answer, which is the reason it has been suggested e.g. >>>>>> not >>>>>to >>>>>> support paralell forking in the browser. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Christer >>>>>> ________________________________________ >>>>>> From: I=F1aki Baz Castillo [ibc@aliax.net >] >>>>>> Sent: Monday, February 20, 2012 10:13 PM >>>>>> To: Christer Holmberg >>>>>> Cc: Justin Uberti; rtcweb@ietf.org ; >>>>>> public-webrtc@w3.org >>>>>> Subject: Re: [rtcweb] JSEP-02: New offer and answer to >previous >>>>>> offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case] >>>>>> >>>>>> 2012/2/20 Christer Holmberg >>>>> >: >>>>>> > Q1. When the JS app requests the new offer (o-2), I assume >>>all >>>>>> resources etc associated with o-1 will be released (unless >>>>>> they >>>>>are >>>>>> also needed for o-2, that is). >>>>>> >>>>>> Does it mean that the browser is just capable of having *one* >>>>>> multimedia session at the same time? Well, in SIP world this >>>>>typically >>>>>> means putting on-hold the previous call so, indeed, resources >>>>>would be >>>>>> released. >>>>>> >>>>>> But, why couldn't the browser send a just-audio offer >>>>>> somewhere >>>>>and a >>>>>> just-video offer to other destination at the same time? >>>>>> >>>>>> -- >>>>>> I=F1aki Baz Castillo >>>>>> > >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>>> >>>>>-- >>>>>Randell Jesup >>>>>randell-ietf@jesup.org >>>>>_______________________________________________ >>>>>rtcweb mailing list >>>>>rtcweb@ietf.org >>>>>https://www.ietf.org/mailman/listinfo/rtcweb From harald@alvestrand.no Mon Feb 27 07:18: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 C47DD21F8794 for ; Mon, 27 Feb 2012 07:18:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.854 X-Spam-Level: X-Spam-Status: No, score=-109.854 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, 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 RTH0hOxfjFZE for ; Mon, 27 Feb 2012 07:18:24 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 4E40721F878E for ; Mon, 27 Feb 2012 07:18:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 57EB139E10E; Mon, 27 Feb 2012 16:18:22 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22KfB7XTUdDI; Mon, 27 Feb 2012 16:18:20 +0100 (CET) Received: from [192.168.1.2] (unknown [46.249.236.98]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 4C01D39E0D2; Mon, 27 Feb 2012 16:18:20 +0100 (CET) Message-ID: <4F4B9EBA.4010900@alvestrand.no> Date: Mon, 27 Feb 2012 16:18:18 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: "Muthu Arul Mozhi Perumal (mperumal)" References: <1D062974A4845E4D8A343C6538049202079972BB@XMB-BGL-414.cisco.com> In-Reply-To: <1D062974A4845E4D8A343C6538049202079972BB@XMB-BGL-414.cisco.com> Content-Type: multipart/alternative; boundary="------------080404060000050107000200" Cc: =?ISO-8859-1?Q?Jos=E9_Ruiz?= , rtcweb@ietf.org, "Michael Ramalho \(mramalho\)" , =?ISO-8859-1?Q?Juli=E1n_Fern=E1ndez_Navajas?= Subject: Re: [rtcweb] FW: Proposal for tunneling, compressing and multiplexing flows 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, 27 Feb 2012 15:18:25 -0000 This is a multi-part message in MIME format. --------------080404060000050107000200 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit On 02/20/2012 07:18 PM, Muthu Arul Mozhi Perumal (mperumal) wrote: > > Any thoughts on how important this is for WebRTC? > I'd say that it is not a problem WebRTC needs to solve - definitely not before getting its basic stuff out the door. > Muthu > > *From:*tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] *On > Behalf Of *Jose Saldana > *Sent:* Thursday, February 16, 2012 9:17 PM > *To:* tsvwg@ietf.org > *Subject:* Proposal for tunneling, compressing and multiplexing flows > > Hello all. > > My name is Jose Saldana, from the University of Zaragoza, in Spain. I > am new in this workgroup. > > Today I have uploaded a new draft: > http://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/: > > Title : Tunneling Compressed Multiplexed > Traffic Flows (TCMTF) > > Author(s) : Jose Saldana > > Filename : draft-saldana-tsvwg-tcmtf-00.txt > > Pages : 16 > > Date : 2012-02-16 > > I am not the sole author of the draft. In fact, six more people have > contributed to build it: Dan Wing (Cisco), Julian Fernandez-Navajas > (Univ. of Zaragoza), Jose Ruiz-Mas (Univ. of Zaragoza), Muthu A. M. > Perumal (Cisco), Gonzalo Camarillo (Ericsson) and Michael Ramalho(Cisco). > > *Abstract*: This document describes a method to improve the bandwidth > utilization of network paths that carry multiple streams in parallel > between two endpoints, as in voice trunking. The method combines > standard protocols that provide compression, multiplexing, and > tunneling over a network path for the purpose of reducing the > bandwidth used when multiple streams are carried over that path. > > The main idea is to update TCRTP. This is a "Best current practice" > RFC (http://datatracker.ietf.org/doc/rfc4170 > ) which was developed in > Audio/Video Transport working group in 2005-11. It "describes a method > to improve the bandwidth utilization of RTP streams over network paths > that carry multiple Real-time Transport Protocol (RTP) streams in > parallel between two endpoints, as in voice trunking. The method > combines standard protocols that provide compression, multiplexing, > and tunneling over a network path for the purpose of reducing the > bandwidth used when multiple RTP streams are carried over that path." > (from the introduction of RFC4170). > > The scheme of TCRTP is: > > RTP/UDP/IP > > | > > | > > ECRTP (compressing layer). Compresses RTP/UDP/IP headers > > | > > | > > PPPMux (multiplexing layer). Includes a number of compressed > packets into a bigger one > > | > > | > > L2TP (tunneling layer). Permits its use end-to-end > > | > > | > > IP > > However, there exist many real-time flows that do not use RTP: > > - Online "First Person Shooter" (FPS) games use UDP datagrams, and > they are one of the most "real-time" applications nowadays. Some > examples: Counter Strike, Halo, Quake, etc.[1]. > > - Online "Massively Multiplayer Online Role Playing Games" (MMORPG): > They use TCP, but can be considered "real-time", since the actions of > the players have to be transmitted very quickly to the server. It > should be taken into account that player vs player fights are one of > the possible activities of the game. Some examples: World of Warcraft > (more than 10 million subscribers) [2]. > > - TCP is also getting used for media delivery. For many reasons, such > as avoiding firewalls, the standard IP/ UDP/ RTP protocol stack is > substituted in many cases by IP/ TCP/ HTTP/ FLV [3]. > > - Another interesting scenario is satellite communication links. > Multiplexing small packets into one packet for transmission would > improve the efficiency. Satellite links would also find it useful to > multiplex small TCP packets into one packet - this could be especially > interesting for compressing TCP ACKs. > > In our recent research activities, we have adapted TCRTP scheme for > its use when the traffic is not RTP. The idea is to substitute ECRTP > by other compression scheme which can be used for UDP or TCP headers. > In 2006, the IETF formed the Robust Header Compression (ROHC) working > group which created specifications for header compression over links > for RTP, UDP and TCP. These specifications were extended to compress > headers over other networks. For most RTP flows, ROHC is more > bandwidth efficient than ECRTP, at the cost of implementation > complexity. It has a special care of context synchronization, defining > some states at the compressor and decompressor. Once the effort for > designing ROHC has been conducted, it is worth including it in the > compressing and multiplexing standard. > > In a recent paper in Nov. issue of IEEE Communications Magazine, it > was shown that 30% of bandwidth saving can be achieved for 8 FPS > different games using IPv4. If IPv6 is used, savings can be up to 54% > [4]. Another recent study, which is still under review, has estimated > 45% bandwidth saving for World of Warcraft. > > After working with other researchers, we have developed a standard. > The possible scheme of the proposal could be this one: > > G.711 or other payload > > | ------------------------------ > > | > > G.711.0 or other payload compression payload compression layer > > | > > | ------------------------------ > > TCP UDP RTP/UDP > > | | | > > \ | / ------------------------------ > > \ | / > > Nothing or ROHC or ECRTP or IPHC header compressing layer > > | > > | ------------------------------ > > | > > PPPMUX or other mux protocols multiplexing layer > > | > > | ------------------------------ > > | > > GRE or L2TP or other tunneling layer > > | > > | ------------------------------ > > IP > > It should be more "open" than TCRTP. I the use of different protocols > could be "orthogonal": different header compression algorithms could > be used, depending on the application and the scenario; also different > multiplexing and tunneling protocols could be included. Finally, > another option has been considered: A payload compression layer. When > the payload is G.711 this layer can runs G.711.0, a lossless and > stateless compression/decompression of the payload [I.711]. This > operations can be deployed by network elements like > routers/switches, without the endpoints having to signal it using > RTSP/SDP/SIP, since G.711 has a fixed RTP payload number. > > Regarding the scenarios, we have considered some of them: > > - A provider of a real-time service (e.g. game or voip) can have an > infrastructure with a number of proxies that can group traffic from > different users and send it to the server. > > - An Internet café, where a number (sometimes big) of players share > the same access link. Bandwidth is scarce in that scenario. > > - A satellite link, where the bandwidth and the pps have to be saved. > > - Desktop or application sharing where the traffic from the server to > the client typically consists of the delta of screen updates. Also, > the standard for remote desktop sharing emerging for WebRTC in the > RTCWEB Working Group is: {something}/SCTP/UDP (Stream Control > Transmission Protocol [SCTP]). In this scenario, SCTP/UDP could be > used in other cases: chatting, file sharing and applications related > to WebRTC peers. There could be hundreds of clients at a site talking > to a server located at a datacenter over a WAN. > > Thank you very much, and sorry for writing such a long message, > > Jose Saldana > > University of Zaragoza > > PS: We have also written a paper, which will be presented in next ICC > conference, in Ottawa in June. You can read a draft here: > http://diec.unizar.es/~jsaldana/personal/widening_scope_draft.pdf > > > ______________ > > [1] Ratti, S.; Hariri, B.; Shirmohammadi, S., "A Survey of > First-Person Shooter Gaming Traffic on the Internet," Internet > Computing, IEEE , vol.14, no.5, pp.60-69, Sept.-Oct. 2010. URL: > http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5445069&isnumber=5562482 > > > [2] P. Svoboda, W Karner and M. Rupp, "Traffic Analysis and Modeling > for World of Warcraft," ICC '07. IEEE International Conference on > Communications, pp.1612-1617, 24-28, Jun. 2007. URL: > http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4288941&isnumber=4288671 > > > [3] G. Marfia and M. Roccetti, "TCP At Last: Reconsidering TCP's Role > for Wireless Entertainment Centers at Home," IEEE Transactions on > Consumer Electronics, Vol. 56, N. 4, Nov. 2010, pp. 2233-2240. URL: > http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5681095&isnumber=5681060 > > > [4] J. Saldana, J. Fernández-Navajas, J. Ruiz-Mas, J. I. Aznar, E. > Viruete and L. Casadesus, "First Person Shooters: Can a Smarter > Network Save Bandwidth without Annoying the Players?," IEEE > Communications Magazine, Consumer Communications and Networking > Series, vol. 49, no. > > 11, pp. 190-198, Nov. 2011. URL: > http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6069728&isnumber=6069696 > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------080404060000050107000200 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 02/20/2012 07:18 PM, Muthu Arul Mozhi Perumal (mperumal) wrote:

Any thoughts on how important this is for WebRTC?

I'd say that it is not a problem WebRTC needs to solve - definitely not before getting its basic stuff out the door.

 

Muthu

 

From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of Jose Saldana
Sent: Thursday, February 16, 2012 9:17 PM
To: tsvwg@ietf.org
Subject: Proposal for tunneling, compressing and multiplexing flows

 

Hello all.

 

My name is Jose Saldana, from the University of Zaragoza, in Spain. I am new in this workgroup.

 

Today I have uploaded a new draft: http://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/:

 

                Title           : Tunneling Compressed Multiplexed Traffic Flows (TCMTF)

                Author(s)       : Jose Saldana

                Filename        : draft-saldana-tsvwg-tcmtf-00.txt

                Pages           : 16

                Date            : 2012-02-16

 

I am not the sole author of the draft. In fact, six more people have contributed to build it: Dan Wing (Cisco), Julian Fernandez-Navajas (Univ. of Zaragoza), Jose Ruiz-Mas (Univ. of Zaragoza), Muthu A. M. Perumal (Cisco), Gonzalo Camarillo (Ericsson) and Michael Ramalho(Cisco).

 

Abstract: This document describes a method to improve the bandwidth utilization  of network paths that carry multiple streams in parallel between two endpoints, as in voice trunking.  The method combines standard  protocols that provide compression, multiplexing, and tunneling over  a network path for the purpose of reducing the bandwidth used when multiple streams are carried over that path.

 

The main idea is to update TCRTP. This is a "Best current practice" RFC (http://datatracker.ietf.org/doc/rfc4170 ) which was developed in Audio/Video Transport working group in 2005-11. It "describes a method to improve the bandwidth utilization of RTP streams over network paths that carry multiple Real-time Transport Protocol (RTP) streams in parallel between two endpoints, as in voice trunking. The method combines standard protocols that provide compression, multiplexing, and tunneling over a network path for the purpose of reducing the bandwidth used when multiple RTP streams are carried over that path." (from the introduction of RFC4170).

 

The scheme of TCRTP is:

 

   RTP/UDP/IP

      |

      |

    ECRTP (compressing layer). Compresses RTP/UDP/IP headers

      |

      |

     PPPMux (multiplexing layer). Includes a number of compressed packets into a bigger one

      |

      |

    L2TP     (tunneling layer). Permits its use end-to-end

      |

      |

      IP

 

However, there exist many real-time flows that do not use RTP:

 

- Online "First Person Shooter" (FPS) games use UDP datagrams, and they are one of the most "real-time" applications nowadays. Some examples: Counter Strike, Halo, Quake, etc.[1].

 

- Online "Massively Multiplayer Online Role Playing Games" (MMORPG): They use TCP, but can be considered "real-time", since the actions of the players have to be transmitted very quickly to the server. It should be taken into account that player vs player fights are one of the possible activities of the game. Some examples: World of Warcraft (more than 10 million subscribers) [2].

 

- TCP is also getting used for media delivery. For many reasons, such as avoiding firewalls, the standard IP/ UDP/ RTP protocol stack is substituted in many cases by IP/ TCP/ HTTP/ FLV [3].

 

- Another interesting scenario is satellite communication links. Multiplexing small packets into one packet for transmission would improve the efficiency. Satellite links would also find it useful to multiplex small TCP packets into one packet - this could be especially interesting for compressing TCP ACKs.

 

 

In our recent research activities, we have adapted TCRTP scheme for its use when the traffic is not RTP. The idea is to substitute ECRTP by other compression scheme which can be used for UDP or TCP headers. In 2006, the IETF formed the Robust Header Compression (ROHC) working group which created specifications for header compression over links for RTP, UDP and TCP.  These specifications were extended to compress headers over other networks. For most RTP flows, ROHC is more bandwidth efficient than ECRTP, at the cost of implementation complexity. It has a special care of context synchronization, defining some states at the compressor and decompressor. Once the effort for designing ROHC has been conducted, it is worth including it in the compressing and multiplexing standard.

 

In a recent paper in Nov. issue of IEEE Communications Magazine, it was shown that 30% of bandwidth saving can be achieved for 8 FPS different games using IPv4. If IPv6 is used, savings can be up to 54% [4]. Another recent study, which is still under review, has estimated 45% bandwidth saving for World of Warcraft.

 

After working with other researchers, we have developed a standard. The possible scheme of the proposal could be this one:

 

        G.711 or other payload

                   |                      ------------------------------

                   |

G.711.0 or other payload compression        payload compression layer

                   |

                   |                      ------------------------------

    TCP    UDP  RTP/UDP

     |      |      |

      \     |     /                       ------------------------------

        \   |   /

Nothing or ROHC or ECRTP or IPHC             header compressing layer

               |

               |                          ------------------------------

               |

   PPPMUX or other mux protocols                multiplexing layer

               |

               |                          ------------------------------

               |

        GRE or L2TP or other                      tunneling layer

               |

               |                          ------------------------------

               IP

 

It should be more "open" than TCRTP. I the use of different protocols could be "orthogonal": different header compression algorithms could be used, depending on the application and the scenario; also different multiplexing and tunneling protocols could be included. Finally, another option has been considered: A payload compression layer.  When the payload is G.711 this layer can runs G.711.0, a  lossless and stateless compression/decompression of the payload  [I.711].  This operations can be deployed by network elements like   routers/switches, without the endpoints having to signal it using   RTSP/SDP/SIP, since G.711 has a fixed RTP payload number.

 

Regarding the scenarios, we have considered some of them:

 

- A provider of a real-time service (e.g. game or voip) can have an infrastructure with a number of proxies that can group traffic from different users and send it to the server.

 

- An Internet café, where a number (sometimes big) of players share the same access link. Bandwidth is scarce in that scenario.

 

- A satellite link, where the bandwidth and the pps have to be saved.

 

- Desktop or application sharing where the traffic from the server to the client typically consists of the delta of screen updates.  Also, the standard for remote desktop sharing emerging for WebRTC in the RTCWEB Working  Group is: {something}/SCTP/UDP (Stream Control Transmission Protocol [SCTP]).  In this scenario, SCTP/UDP could be used in other cases:  chatting, file sharing and applications related to WebRTC peers. There could be hundreds of clients at a site talking to a server located at a datacenter over a WAN.

 

Thank you very much, and sorry for writing such a long message,

 

Jose Saldana

University of Zaragoza

 

PS: We have also written a paper, which will be presented in next ICC conference, in Ottawa in June. You can read a draft here: http://diec.unizar.es/~jsaldana/personal/widening_scope_draft.pdf

 

______________

 

[1] Ratti, S.; Hariri, B.; Shirmohammadi, S., "A Survey of First-Person Shooter Gaming Traffic on the Internet," Internet Computing, IEEE , vol.14, no.5, pp.60-69, Sept.-Oct. 2010. URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5445069&isnumber=5562482

 

[2] P. Svoboda, W Karner and M. Rupp, "Traffic Analysis and Modeling for World of Warcraft," ICC '07. IEEE International Conference on Communications, pp.1612-1617, 24-28, Jun. 2007. URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4288941&isnumber=4288671

 

[3] G. Marfia and M. Roccetti, "TCP At Last: Reconsidering TCP's Role for Wireless Entertainment Centers at Home," IEEE Transactions on Consumer Electronics, Vol. 56, N. 4, Nov. 2010, pp. 2233-2240. URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5681095&isnumber=5681060

 

[4] J. Saldana, J. Fernández-Navajas, J. Ruiz-Mas, J. I. Aznar, E. Viruete and  L. Casadesus, "First Person Shooters: Can a Smarter Network Save Bandwidth without Annoying the Players?," IEEE Communications Magazine, Consumer Communications and Networking Series, vol. 49, no.

11, pp. 190-198, Nov. 2011. URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6069728&isnumber=6069696

 

 


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

--------------080404060000050107000200-- From Ranjit.Avasarala@Polycom.com Wed Feb 29 06:24: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 EDD3A21F8736 for ; Wed, 29 Feb 2012 06:24:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.374 X-Spam-Level: X-Spam-Status: No, score=-3.374 tagged_above=-999 required=5 tests=[AWL=-1.776, BAYES_00=-2.599, GB_SUMOF=5, 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 Gs1ADgFW+7Ih for ; Wed, 29 Feb 2012 06:24:17 -0800 (PST) Received: from Hkgehubprd01.polycom.com (hkgehubprd01.polycom.com [140.242.6.225]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0C521F8724 for ; Wed, 29 Feb 2012 06:24:15 -0800 (PST) Received: from hkgmboxprd22.polycom.com ([fe80::c4c3:4566:8b3b:ec85]) by Hkgehubprd01.polycom.com ([fe80::5efe:172.21.6.201%12]) with mapi; Wed, 29 Feb 2012 22:24:14 +0800 From: "Avasarala, Ranjit" To: "Ravindran, Parthasarathi" , "Ejzak, Richard P (Richard)" , Roman Shpount Date: Wed, 29 Feb 2012 22:20:07 +0800 Thread-Topic: [rtcweb] Consensus call on JSEP/ROAP Thread-Index: AQHM5daOqyJlzHkk1UCHKJfTYUstZ5ZHSnCAgAA4QACAACbCgIAACJIAgAAEXACAAAYmAIADtmvggAib2j8= Message-ID: <1F2A2C70609D9E41844A2126145FC09804BC2DC3BA@HKGMBOXPRD22.polycom.com> References: <6F428EFD2B8C2F49A2FB1317291A76C11355D49DF5@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <005BC7E2-88EE-4D8F-8AEA-4614D39A6DC6@employees.org> <6F428EFD2B8C2F49A2FB1317291A76C11355D4A12E@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <6F428EFD2B8C2F49A2FB1317291A76C11355D4A14E@USNAVSXCHMBSA1.ndc.alcatel-lucent.com>, <387F9047F55E8C42850AD6B3A7A03C6C0E04CD6A@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E04CD6A@inba-mail01.sonusnet.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_1F2A2C70609D9E41844A2126145FC09804BC2DC3BAHKGMBOXPRD22p_" MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consensus call on JSEP/ROAP 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, 29 Feb 2012 14:24:19 -0000 --_000_1F2A2C70609D9E41844A2126145FC09804BC2DC3BAHKGMBOXPRD22p_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Partha I agree with you that websites need not interop with each other and they ca= n have their own proprietary signaling. But the webservers may need to inte= rop and need to support standard signaling protocols to work with other ser= vers like SIP or media servers. so then we need to have some protocol as the default one (E.g. SIP) and if = there is no signaling protocol mentioned, then assume the protocol to be SI= P. I think this is where the draft on SIP over Websockets becomes important wh= en Websockets is used as a transport for carrying signaling messages betwee= n web browsers and web servers. Regards Ranjit ________________________________ From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] On Behalf Of Ravind= ran, Parthasarathi [pravindran@sonusnet.com] Sent: Monday, February 27, 2012 7:51 AM To: Ejzak, Richard P (Richard); Roman Shpount Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Consensus call on JSEP/ROAP Hi Richard, For your first mail on standard signaling, I would say that =93Welcome to W= ebRTC signaling=94. In fact, I had same expectation of standard signaling a= s yours 6 months back, Please see WebRTC archive for more details. But, Web= RTC (wire) signaling protocol will be proprietary per website. The reason f= or this approach is that there is no need to interop between two different = WebRTC sites and same JS (signaling protocol) is executed in all the clien= t within the single website. For example, www.partha.com will have partha protocol and www.richard.com = will have Richard protocol wherein partha site and Richard site will never = interop with each other. Even if they decide to interop, it is upto Partha = & Richard to decide what is the choice of signaling protocol and no need of= standard at this moment. We may wish to have later :). Hope this clarifie= s your doubt on signaling wire protocol. The aim of WebRTC signaling discussion is to verify whether JSEP (WebRTC si= gnaling protocol in API) defines the basic set of signaling protocol primit= ives like offer/answer which helps to develop any kind of proprietary/stand= ard protocol in the wire. So, it is perfectly valid to discuss proprietary = SIP callflow which are prevalent in the deployment in WebRTC mailing list a= nd it will be considered as one WebRTC application. AFAIK, media protocol= (SRTP, ICE) standard are followed in the normal standard fashion as differ= ent browsers (like Chrome, IE, Mozilla) and other WebRTC clients (gateways)= has to interop. As lot of standard SIP implementation exists, let us review JSEP in a way t= hat JSEP protocol develop JS application which helps to interop with standa= rd SIP but it is not the main motive of this group. Thanks Partha From: rtcweb-bounces@ietf.org [mailto:rtcwe= b-bounces@ietf.org] On Behalf Of Ejzak, Richard P (Richard) Sent: Wednesday, February 22, 2012 5:11 AM To: Roman Shpount Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Consensus call on JSEP/ROAP Hi Roman, You are correct that parallel forking is needed to model this case. I mean= t to distinguish between cases where the previous dialog is cleared immedia= tely upon receipt of a new dialog, compared to the case where multiple dial= ogs are maintained in parallel, and I messed up. Thanks. Richard ________________________________ From: Roman Shpount [mailto:roman@telurix.com] Sent: Tuesday, February 21, 2012 5:19 PM To: Ejzak, Richard P (Richard) Cc: Cary W FitzGerald; rtcweb@ietf.org Subject: Re: [rtcweb] Consensus call on JSEP/ROAP Hi Richard, I must apologize as well, since I know that this issue was discussed before= on the list and decision was made to support multiple provisional response= s. I am not sure there was a consensus call on it, but it looked like work = group decided to implement this in both ROAP and JSEP. I see your point abo= ut standards, but unfortunately real life is often different. You proposal in another thread is only an acceptable compromise if parallel= forking is supported. If parallel forking is supported, each new provision= al SDP can be treated as a new parallel fork and the previous media connect= ion can be discarded. _____________ Roman Shpount On Tue, Feb 21, 2012 at 6:02 PM, Ejzak, Richard P (Richard) > wrote: Hi Roman, If this issue has already been debated in the group, I must apologize. But= if standards had to accommodate every non-standard implementation in exist= ence then we wouldn=92t be able to accomplish much=85 I proposed in another thread that we model this kind of behavior with stand= ard SIP serial forking, which JSEP must be able to support. The SIP isn=92= t exactly the same, but the offer/answer sequence is. This allows implemen= tations to realize this flow in practice if necessary without encoding it i= n our specs. Could this be an acceptable compromise? Richard ________________________________ From: Roman Shpount [mailto:roman@telurix.com] Sent: Tuesday, February 21, 2012 4:32 PM To: Cary W FitzGerald Cc: Ejzak, Richard P (Richard); rtcweb@ietf.org Subject: Re: [rtcweb] Consensus call on JSEP/ROAP Another issue is that real-life SIP deployments are often not RFC 3264 comp= laint. In particular it is not unusual to receive different SDP in provisio= nal and final INVITE response. This does not fit offer/answer model since i= t implies multiple answers to one offer with subsequent answers overwriting= previous ones. So, offer/answer compliance is insufficient even for the SI= P interop. _____________ Roman Shpount On Tue, Feb 21, 2012 at 3:13 PM, Cary W FitzGerald > wrote: This is partially inevitable. For WebRTC applications that interact with S= IP gateways, the WebRTC application can't signal anything that 3264 won't a= llow, since the gateway's side won't be able to deal with it. The original= architecture document http://tools.ietf.org/html/draft-ietf-rtcweb-overvie= w-02 proposes a RTC trapezoid and any well-behaved trapezoid needs to consi= der the SIP case and therefore 3264. There is another important case, which is when the trapezoid degenerates in= to a triangle. This is the case where the web server controls both sides o= f the conversation (e.g. connecting to an attendant at www.ftd.com without any intervening PBX/switch/traditional contact center).= Since there is no PSTN GW to contend with, it's not necessary to obey the= gateway's rules. In this case, the server presumably knows what it's doin= g, so it's probably a bug if it trips itself up. There is potentially a third case, which is where the trapezoid is maintain= ed, and the servers are communicating with some-protocol-not-SIP that doesn= 't need to abide by 3264 (which excludes H.323), but are not smart enough t= o coordinate media between themselves, but this doesn't seem very important= . I could be wrong about that, but I don't see the practical use case. Cary. On Feb 21, 2012, at 8:52 AM, Ejzak, Richard P (Richard) wrote: Hi All, I would like to point out that if you rephrase the question to ask "who pre= fers to base subsequent work on RFC 3264 semantics?", then you would need t= o combine positions 2 and 4, and you would get a vote of 28 (the position 3= votes) for a new semantic model (requiring significant new work on SDP) ag= ainst 21 (the sum of votes for positions 2 and 4) for RFC 3264 semantics. So while I do not object to using JSEP as a basis for further work, it seem= s that the group is far less certain about the on-the-wire semantics to be = associated with it. My preference is to focus on RFC 3264 semantics (notin= g that the low level of the API would still allow considerable flexibility = to support other signaling protocols). My key concern is to have clear rul= es (based on common semantics) for interworking media/transport negotiation= procedures between different on-the-wire protocols to avoid potential inte= rop problems. In particular, at this point in the discussion, I do not see the value of a= llowing multiple open OFFERs within a dialog (which have acknowledged probl= ems), multiple ANSWERs within a dialog, or PRANSWERs, none of which exist i= n RFC 3264. I propose that the group first decide whether to use JSEP as a basis for fu= rther work and in subsequent step(s) decide whether and how to go beyond RF= C 3264 semantics. I see this proposal as simply a clarification of the mea= ning of position 3. Richard Ejzak -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcwe= b-bounces@ietf.org] On Behalf Of Ted Hardie Sent: Tuesday, February 07, 2012 2:25 PM To: rtcweb@ietf.org Subject: [rtcweb] Consensus call on JSEP/ROAP During the interim meeting, the attendees discussed the JSEP and ROAP proposals. The chairs also asked the working group to consider whether they might be successfully merged. Because of audio difficulties, there is no recording available. The jabber logs contain a transcription of the discussion by Bernard Aboba and can be found here: http://www.ietf.org/jabber/logs/rtcweb/2012-01-31.html. At the end of the discussion, the chairs asked the attendees to indicate their preferences by standing for one of four positions, which wer= e listed prior to the question being called. The positions were: 1--Don't care whether ROAP or JSEP is the input document for further work in this area 2---Prefer ROAP be the input document for further work 3--Prefer JSEP be the input document for further work 4--Prefer to merge the docs, limiting JSEP to RFC 3264 offer/answer semanti= cs. The results were: 1=3D9 in room, none in jabber 2=3D11 in room, 2 in jabber 3=3D25 in room, 3 in jabber 4=3D8 in room, none in jabber. Because JSEP supports more than one model of negotiation, choosing 3 is a reversal from previous working group consensus to limit work to the offer/answer model. The chairs are now calling for consensus of the working group on this point. Working group participants who were not present at the interim, please review the input documents if you not have yet done so, and forward your comments to the list. All working group participants are asked to make their points on this topic by February 22nd, so that we have timely input prior to the document deadline for Paris. thanks, Ted Hardie for the Chairs _______________________________________________ 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 --_000_1F2A2C70609D9E41844A2126145FC09804BC2DC3BAHKGMBOXPRD22p_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi Partha
 
I agree with you that websites need not= interop with each other and they can have their own proprietary signaling.= But the webservers may need to interop and need to support standard signal= ing protocols to work with other servers like SIP or media servers.
 
so then we need to have some protocol a= s the default one (E.g. SIP) and if there is no signaling protocol mentione= d, then assume the protocol to be SIP.
 
I think this is where the draft on SIP = over Websockets becomes important when Websockets is used as a transport fo= r carrying signaling messages between web browsers and web servers.<= /div>
 
 
Regards
Ranjit
 
From: rtcweb-boun= ces@ietf.org [rtcweb-bounces@ietf.org] On Behalf Of Ravindran, Parthasarath= i [pravindran@sonusnet.com]
Sent: Monday, February 27, 2012 7:51 AM
To: Ejzak, Richard P (Richard); Roman Shpount
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Consensus call on JSEP/ROAP

Hi Richard,

 

For your first mail on standard signaling,= I would say that =93Welcome to WebRTC signaling=94. In fact, I had same ex= pectation of standard signaling as yours 6 months back, Please see WebRTC archive for more details. But, WebRTC (wi= re) signaling protocol will be proprietary per website. The reason for this= approach is that there is no need to interop between two different WebRTC = sites and same  JS (signaling protocol) is executed in all the client within the single website. For example, www.partha.com will have partha protocol and www.richard.com will have Richard protocol wherein partha site and Rich= ard site will never interop with each other. Even if they decide to interop= , it is upto Partha & Richard to decide what is the choice of signaling= protocol and no need of standard at this moment. We may wish to have later  J. Hope = this clarifies your doubt on signaling wire protocol.

 

The aim of WebRTC signaling discussion is = to verify whether JSEP (WebRTC signaling protocol in API) defines the basic= set of signaling protocol primitives like offer/answer which helps to develop any kind of proprietary/standard = protocol in the wire. So, it is perfectly valid to discuss proprietary SIP = callflow which are prevalent in the deployment in WebRTC mailing list and i= t will be considered as one WebRTC application.   AFAIK, media protocol (SRTP, ICE) standard are fo= llowed in the normal standard fashion as different browsers (like Chrome, I= E, Mozilla) and other WebRTC clients (gateways) has to interop.

 

As lot of standard SIP implementation exis= ts, let us review JSEP in a way that JSEP protocol develop JS application w= hich helps to interop with standard SIP but it is not the main motive of this group.

 

Thanks

Partha

 

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ejzak, Richard P (Richard)
Sent: Wednesday, February 22, 2012 5:11 AM
To: Roman Shpount
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Consensus call on JSEP/ROAP

 

Hi Roman,

You are correct that parallel forking is needed= to model this case.  I meant to distinguish between cases where the p= revious dialog is cleared immediately upon receipt of a new dialog, compared to the case where multiple dialogs are m= aintained in parallel, and I messed up.  Thanks.

 

Richard

 

From: Roman Shpount [mailto:roman@telurix.com]
Sent: Tuesday, February 21, 2012 5:19 PM
To: Ejzak, Richard P (Richard)
Cc: Cary W FitzGerald; rtcweb@iet= f.org
Subject: Re: [rtcweb] Consensus call on JSEP/ROAP

 

Hi Richard,

I must apologize as well, since I know that this issue was discussed before= on the list and decision was made to support multiple provisional response= s. I am not sure there was a consensus call on it, but it looked like work = group decided to implement this in both ROAP and JSEP. I see your point about standards, but unfortunately= real life is often different.

You proposal in another thread is only an acceptable compromise if parallel= forking is supported. If parallel forking is supported, each new provision= al SDP can be treated as a new parallel fork and the previous media connect= ion can be discarded.
_____________
Roman Shpount

On Tue, Feb 21, 2012 at 6:02 PM, Ejzak, Richard P (R= ichard) <richard.ejz= ak@alcatel-lucent.com> wrote:

Hi Roman,

If this issue has already been debated in the g= roup, I must apologize.  But if standards had to accommodate every non= -standard implementation in existence then we wouldn=92t be able to accomplish much=85

 

I proposed in another thread that we model this= kind of behavior with standard SIP serial forking, which JSEP must be able= to support.  The SIP isn=92t exactly the same, but the offer/answer sequence is.  This allows implementati= ons to realize this flow in practice if necessary without encoding it in ou= r specs.  Could this be an acceptable compromise?

 

Richard

 

From: Roman Shpount [mailto:roman@telurix.com]
Sent: Tuesday, February 21, 2012 4:32 PM
To: Cary W FitzGerald
Cc: Ejzak, Richard P (Richard); r= tcweb@ietf.org
Subject: Re: [rtcweb] Consensus call on JSEP/ROAP

 

Another issue is that = real-life SIP deployments are often not RFC 3264 complaint. In particular i= t is not unusual to receive different SDP in provisional and final INVITE r= esponse. This does not fit offer/answer model since it implies multiple answers to one offer with subsequent answe= rs overwriting previous ones. So, offer/answer compliance is insufficient e= ven for the SIP interop.
_____________
Roman Shpount

On Tue, Feb 21, 2012 at 3:13 PM, Cary W FitzGerald &= lt;caryfitz@employees.org>= wrote:

This is partially inevitable.  For WebRTC appli= cations that interact with SIP gateways, the WebRTC application can't signa= l anything that 3264 won't allow, since the gateway's side won't be able to= deal with it.  The original architecture document http://tools.ietf.org/html/draft-ietf-rtcweb-ove= rview-02 proposes a RTC trapezoid and any well-behaved trapezoid n= eeds to consider the SIP case and therefore 3264.

 

There is another important case, which is when the t= rapezoid degenerates into a triangle.  This is the case where the web = server controls both sides of the conversation (e.g. connecting to an atten= dant at www.ftd.com without an= y intervening PBX/switch/traditional contact center).  Since there is = no PSTN GW to contend with, it's not necessary to obey the gateway's rules.=  In this case, the server presumably knows what it's doing, so it's probably a bug if it trips itself up.

 

There is potentially a third case, which is where th= e trapezoid is maintained, and the servers are communicating with some-prot= ocol-not-SIP that doesn't need to abide by 3264 (which excludes H.323), but= are not smart enough to coordinate media between themselves, but this doesn't seem very important.  I co= uld be wrong about that, but I don't see the practical use case.

 

Cary.

 

On Feb 21, 2012, at 8:52 AM, Ejzak, Richard P (Richa= rd) wrote:

 

Hi All,
I would like to point out that if you rephrase the question to ask "wh= o prefers to base subsequent work on RFC 3264 semantics?", then you wo= uld need to combine positions 2 and 4, and you would get a vote of 28 (the = position 3 votes) for a new semantic model (requiring significant new work on SDP) against 21 (the sum of votes for p= ositions 2 and 4) for RFC 3264 semantics.

So while I do not object to using JSEP as a basis for further work, it seem= s that the group is far less certain about the on-the-wire semantics to be = associated with it.  My preference is to focus on RFC 3264 semantics (= noting that the low level of the API would still allow considerable flexibility to support other signaling prot= ocols).  My key concern is to have clear rules (based on common semant= ics) for interworking media/transport negotiation procedures between differ= ent on-the-wire protocols to avoid potential interop problems.  

In particular, at this point in the discussion, I do not see the value of a= llowing multiple open OFFERs within a dialog (which have acknowledged probl= ems), multiple ANSWERs within a dialog, or PRANSWERs, none of which exist i= n RFC 3264.

I propose that the group first decide whether to use JSEP as a basis for fu= rther work and in subsequent step(s) decide whether and how to go beyond RF= C 3264 semantics.  I see this proposal as simply a clarification of th= e meaning of position 3.

Richard Ejzak

-----Original Message-----
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.or= g] On Behalf Of Ted Hardie
Sent: Tuesday, February 07, 2012 2:25 PM
To: rtcweb@ietf.org
Subject: [rtcweb] Consensus call on JSEP/ROAP

During the interim meeting, the attendees discussed the JSEP and ROAP
proposals.  The chairs also asked the working group to consider
whether they might be successfully merged.  Because of audio difficult= ies,
there is no recording available.  The jabber logs contain
a transcription of the discussion by Bernard Aboba and can be found
here: http://www.ietf.org/jabber/logs/rtcweb/2012-01-31.html.

At the end of the discussion, the chairs asked the attendees to
indicate their preferences by standing for one of four positions, which wer= e
listed prior to the question being called.  The positions were:

1--Don't care whether ROAP or JSEP is the input document for further
work in this area

2---Prefer ROAP be the input document for further work

3--Prefer JSEP be the input document for further work

4--Prefer to merge the docs, limiting JSEP to RFC 3264 offer/answer semanti= cs.

The results were: 1=3D9 in room, none in jabber
            &nb= sp;            =    2=3D11 in room, 2 in jabber
            &nb= sp;            =    3=3D25 in room, 3 in jabber
            &nb= sp;            =    4=3D8 in room, none in jabber.

Because JSEP supports more than one model of negotiation, choosing 3
is a reversal  from previous working group consensus to limit work to<= br> the offer/answer model.

The chairs are now calling for consensus of the working group on this
point.  Working group participants who were not present at the interim= ,
please review the input documents if you not have yet done so, and
forward your comments to the list.  All working group participants are=
asked to make
their points on this topic by February 22nd, so that we have timely
input prior to the document deadline for Paris.

thanks,

Ted Hardie for the Chairs
_______________________________________________
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

 

 

--_000_1F2A2C70609D9E41844A2126145FC09804BC2DC3BAHKGMBOXPRD22p_-- From pravindran@sonusnet.com Wed Feb 29 08: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 063FE21F8746 for ; Wed, 29 Feb 2012 08:05:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.156 X-Spam-Level: X-Spam-Status: No, score=0.156 tagged_above=-999 required=5 tests=[AWL=-2.246, BAYES_00=-2.599, GB_SUMOF=5, 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 t1dGYib3LviA for ; Wed, 29 Feb 2012 08:05:16 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 5621A21F8742 for ; Wed, 29 Feb 2012 08:05:15 -0800 (PST) Received: from sonusmail05.sonusnet.com (sonusmail05.sonusnet.com [10.128.32.155]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q1TG5vuc029427; Wed, 29 Feb 2012 11:05:57 -0500 Received: from USMA-EX-HUB2.sonusnet.com ([66.203.90.17]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 29 Feb 2012 11:05:08 -0500 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, 29 Feb 2012 11:05:09 -0500 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, 29 Feb 2012 21:35:04 +0530 From: "Ravindran, Parthasarathi" To: "Avasarala, Ranjit" , "Ejzak, Richard P (Richard)" , Roman Shpount Thread-Topic: [rtcweb] Consensus call on JSEP/ROAP Thread-Index: AQHM5daOqyJlzHkk1UCHKJfTYUstZ5ZHSnCAgAA4QACAACbCgIAACJIAgAAEXACAAAYmAIADtmvggAib2j+AAAIE0A== Date: Wed, 29 Feb 2012 16:05:03 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E05647F@inba-mail01.sonusnet.com> References: <6F428EFD2B8C2F49A2FB1317291A76C11355D49DF5@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <005BC7E2-88EE-4D8F-8AEA-4614D39A6DC6@employees.org> <6F428EFD2B8C2F49A2FB1317291A76C11355D4A12E@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <6F428EFD2B8C2F49A2FB1317291A76C11355D4A14E@USNAVSXCHMBSA1.ndc.alcatel-lucent.com>, <387F9047F55E8C42850AD6B3A7A03C6C0E04CD6A@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804BC2DC3BA@HKGMBOXPRD22.polycom.com> In-Reply-To: <1F2A2C70609D9E41844A2126145FC09804BC2DC3BA@HKGMBOXPRD22.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: multipart/alternative; boundary="_000_387F9047F55E8C42850AD6B3A7A03C6C0E05647Finbamail01sonus_" MIME-Version: 1.0 X-OriginalArrivalTime: 29 Feb 2012 16:05:08.0337 (UTC) FILETIME=[E869BE10:01CCF6FB] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consensus call on JSEP/ROAP 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, 29 Feb 2012 16:05:23 -0000 --_000_387F9047F55E8C42850AD6B3A7A03C6C0E05647Finbamail01sonus_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ranjit, It depends upon the web servers federation protocol choice. The choices of = federation protocol may be standard protocol like SIP, Jingle or the propr= ietary protocol of site choice. I agree with you that existing VoIP/UC/T= elecom deployments will prefer SIP as a federation protocol but we may not = able to generalize it in RTCWeb. SIP over Websocket is not really required in case JSEP is the choice of bro= wser API protocol. IMO, SIP over Websocket is a overkill as there is no ne= ed of SIP routing header like via, max-forward, route are not required betw= een webserver and browser. The simple protocol mapping between Standard SIP= and JSEP will serve the purpose. Thanks Partha From: Avasarala, Ranjit [mailto:Ranjit.Avasarala@Polycom.com] Sent: Wednesday, February 29, 2012 7:50 PM To: Ravindran, Parthasarathi; Ejzak, Richard P (Richard); Roman Shpount Cc: rtcweb@ietf.org Subject: RE: [rtcweb] Consensus call on JSEP/ROAP Hi Partha I agree with you that websites need not interop with each other and they ca= n have their own proprietary signaling. But the webservers may need to inte= rop and need to support standard signaling protocols to work with other ser= vers like SIP or media servers. so then we need to have some protocol as the default one (E.g. SIP) and if = there is no signaling protocol mentioned, then assume the protocol to be SI= P. I think this is where the draft on SIP over Websockets becomes important wh= en Websockets is used as a transport for carrying signaling messages betwee= n web browsers and web servers. Regards Ranjit ________________________________ From: rtcweb-bounces@ietf.org [rtcweb-bounc= es@ietf.org] On Behalf Of Ravindran, Parthasarathi [pravindran@sonusnet.com= ] Sent: Monday, February 27, 2012 7:51 AM To: Ejzak, Richard P (Richard); Roman Shpount Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Consensus call on JSEP/ROAP Hi Richard, For your first mail on standard signaling, I would say that "Welcome to Web= RTC signaling". In fact, I had same expectation of standard signaling as yo= urs 6 months back, Please see WebRTC archive for more details. But, WebRTC = (wire) signaling protocol will be proprietary per website. The reason for t= his approach is that there is no need to interop between two different WebR= TC sites and same JS (signaling protocol) is executed in all the client wi= thin the single website. For example, www.partha.com= will have partha protocol and www.richard.com will= have Richard protocol wherein partha site and Richard site will never inte= rop with each other. Even if they decide to interop, it is upto Partha & Ri= chard to decide what is the choice of signaling protocol and no need of sta= ndard at this moment. We may wish to have later :). Hope this clarifies yo= ur doubt on signaling wire protocol. The aim of WebRTC signaling discussion is to verify whether JSEP (WebRTC si= gnaling protocol in API) defines the basic set of signaling protocol primit= ives like offer/answer which helps to develop any kind of proprietary/stand= ard protocol in the wire. So, it is perfectly valid to discuss proprietary = SIP callflow which are prevalent in the deployment in WebRTC mailing list a= nd it will be considered as one WebRTC application. AFAIK, media protocol= (SRTP, ICE) standard are followed in the normal standard fashion as differ= ent browsers (like Chrome, IE, Mozilla) and other WebRTC clients (gateways)= has to interop. As lot of standard SIP implementation exists, let us review JSEP in a way t= hat JSEP protocol develop JS application which helps to interop with standa= rd SIP but it is not the main motive of this group. Thanks Partha From: rtcweb-bounces@ietf.org [mailto:rtcwe= b-bounces@ietf.org] On Behalf Of Ejzak, Richard P (Richard) Sent: Wednesday, February 22, 2012 5:11 AM To: Roman Shpount Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Consensus call on JSEP/ROAP Hi Roman, You are correct that parallel forking is needed to model this case. I mean= t to distinguish between cases where the previous dialog is cleared immedia= tely upon receipt of a new dialog, compared to the case where multiple dial= ogs are maintained in parallel, and I messed up. Thanks. Richard ________________________________ From: Roman Shpount [mailto:roman@telurix.com] Sent: Tuesday, February 21, 2012 5:19 PM To: Ejzak, Richard P (Richard) Cc: Cary W FitzGerald; rtcweb@ietf.org Subject: Re: [rtcweb] Consensus call on JSEP/ROAP Hi Richard, I must apologize as well, since I know that this issue was discussed before= on the list and decision was made to support multiple provisional response= s. I am not sure there was a consensus call on it, but it looked like work = group decided to implement this in both ROAP and JSEP. I see your point abo= ut standards, but unfortunately real life is often different. You proposal in another thread is only an acceptable compromise if parallel= forking is supported. If parallel forking is supported, each new provision= al SDP can be treated as a new parallel fork and the previous media connect= ion can be discarded. _____________ Roman Shpount On Tue, Feb 21, 2012 at 6:02 PM, Ejzak, Richard P (Richard) > wrote: Hi Roman, If this issue has already been debated in the group, I must apologize. But= if standards had to accommodate every non-standard implementation in exist= ence then we wouldn't be able to accomplish much... I proposed in another thread that we model this kind of behavior with stand= ard SIP serial forking, which JSEP must be able to support. The SIP isn't = exactly the same, but the offer/answer sequence is. This allows implementa= tions to realize this flow in practice if necessary without encoding it in = our specs. Could this be an acceptable compromise? Richard ________________________________ From: Roman Shpount [mailto:roman@telurix.com] Sent: Tuesday, February 21, 2012 4:32 PM To: Cary W FitzGerald Cc: Ejzak, Richard P (Richard); rtcweb@ietf.org Subject: Re: [rtcweb] Consensus call on JSEP/ROAP Another issue is that real-life SIP deployments are often not RFC 3264 comp= laint. In particular it is not unusual to receive different SDP in provisio= nal and final INVITE response. This does not fit offer/answer model since i= t implies multiple answers to one offer with subsequent answers overwriting= previous ones. So, offer/answer compliance is insufficient even for the SI= P interop. _____________ Roman Shpount On Tue, Feb 21, 2012 at 3:13 PM, Cary W FitzGerald > wrote: This is partially inevitable. For WebRTC applications that interact with S= IP gateways, the WebRTC application can't signal anything that 3264 won't a= llow, since the gateway's side won't be able to deal with it. The original= architecture document http://tools.ietf.org/html/draft-ietf-rtcweb-overvie= w-02 proposes a RTC trapezoid and any well-behaved trapezoid needs to consi= der the SIP case and therefore 3264. There is another important case, which is when the trapezoid degenerates in= to a triangle. This is the case where the web server controls both sides o= f the conversation (e.g. connecting to an attendant at www.ftd.com without any intervening PBX/switch/traditional contact center).= Since there is no PSTN GW to contend with, it's not necessary to obey the= gateway's rules. In this case, the server presumably knows what it's doin= g, so it's probably a bug if it trips itself up. There is potentially a third case, which is where the trapezoid is maintain= ed, and the servers are communicating with some-protocol-not-SIP that doesn= 't need to abide by 3264 (which excludes H.323), but are not smart enough t= o coordinate media between themselves, but this doesn't seem very important= . I could be wrong about that, but I don't see the practical use case. Cary. On Feb 21, 2012, at 8:52 AM, Ejzak, Richard P (Richard) wrote: Hi All, I would like to point out that if you rephrase the question to ask "who pre= fers to base subsequent work on RFC 3264 semantics?", then you would need t= o combine positions 2 and 4, and you would get a vote of 28 (the position 3= votes) for a new semantic model (requiring significant new work on SDP) ag= ainst 21 (the sum of votes for positions 2 and 4) for RFC 3264 semantics. So while I do not object to using JSEP as a basis for further work, it seem= s that the group is far less certain about the on-the-wire semantics to be = associated with it. My preference is to focus on RFC 3264 semantics (notin= g that the low level of the API would still allow considerable flexibility = to support other signaling protocols). My key concern is to have clear rul= es (based on common semantics) for interworking media/transport negotiation= procedures between different on-the-wire protocols to avoid potential inte= rop problems. In particular, at this point in the discussion, I do not see the value of a= llowing multiple open OFFERs within a dialog (which have acknowledged probl= ems), multiple ANSWERs within a dialog, or PRANSWERs, none of which exist i= n RFC 3264. I propose that the group first decide whether to use JSEP as a basis for fu= rther work and in subsequent step(s) decide whether and how to go beyond RF= C 3264 semantics. I see this proposal as simply a clarification of the mea= ning of position 3. Richard Ejzak -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcwe= b-bounces@ietf.org] On Behalf Of Ted Hardie Sent: Tuesday, February 07, 2012 2:25 PM To: rtcweb@ietf.org Subject: [rtcweb] Consensus call on JSEP/ROAP During the interim meeting, the attendees discussed the JSEP and ROAP proposals. The chairs also asked the working group to consider whether they might be successfully merged. Because of audio difficulties, there is no recording available. The jabber logs contain a transcription of the discussion by Bernard Aboba and can be found here: http://www.ietf.org/jabber/logs/rtcweb/2012-01-31.html. At the end of the discussion, the chairs asked the attendees to indicate their preferences by standing for one of four positions, which wer= e listed prior to the question being called. The positions were: 1--Don't care whether ROAP or JSEP is the input document for further work in this area 2---Prefer ROAP be the input document for further work 3--Prefer JSEP be the input document for further work 4--Prefer to merge the docs, limiting JSEP to RFC 3264 offer/answer semanti= cs. The results were: 1=3D9 in room, none in jabber 2=3D11 in room, 2 in jabber 3=3D25 in room, 3 in jabber 4=3D8 in room, none in jabber. Because JSEP supports more than one model of negotiation, choosing 3 is a reversal from previous working group consensus to limit work to the offer/answer model. The chairs are now calling for consensus of the working group on this point. Working group participants who were not present at the interim, please review the input documents if you not have yet done so, and forward your comments to the list. All working group participants are asked to make their points on this topic by February 22nd, so that we have timely input prior to the document deadline for Paris. thanks, Ted Hardie for the Chairs _______________________________________________ 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 --_000_387F9047F55E8C42850AD6B3A7A03C6C0E05647Finbamail01sonus_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ranjit,

 <= /p>

It depends upon the web s= ervers federation protocol choice. The choices of federation protocol may b= e standard protocol like SIP, Jingle  or the proprietary protocol of site choice.    I agree with you that existing = VoIP/UC/Telecom deployments will prefer SIP as a federation protocol but we= may not able to generalize it in RTCWeb.

 <= /p>

SIP over Websocket is not= really required in case JSEP is the choice of browser API protocol.  = IMO, SIP over Websocket is a overkill as there is no need of SIP routing header like via, max-forward, route are not required between w= ebserver and browser. The simple protocol mapping between Standard SIP and = JSEP will serve the purpose.

 <= /p>

Thanks<= /p>

Partha<= /p>

 <= /p>

From: Avasaral= a, Ranjit [mailto:Ranjit.Avasarala@Polycom.com]
Sent: Wednesday, February 29, 2012 7:50 PM
To: Ravindran, Parthasarathi; Ejzak, Richard P (Richard); Roman Shpo= unt
Cc: rtcweb@ietf.org
Subject: RE: [rtcweb] Consensus call on JSEP/ROAP<= /p>

 

Hi Partha=

 

I agree= with you that websites need not interop with each other and they can have = their own proprietary signaling. But the webservers may need to interop and= need to support standard signaling protocols to work with other servers like SIP or media servers.

 

so then= we need to have some protocol as the default one (E.g. SIP) and if there i= s no signaling protocol mentioned, then assume the protocol to be SIP.

 

I think= this is where the draft on SIP over Websockets becomes important when Webs= ockets is used as a transport for carrying signaling messages between web b= rowsers and web servers.<= /p>

 

 

Regards

Ranjit

 

From: rtcweb-bounces@ietf.org [rtc= web-bounces@ietf.org] On Behalf Of Ravindran, Parthasarathi [pravindran@son= usnet.com]
Sent: Monday, February 27, 2012 7:51 AM
To: Ejzak, Richard P (Richard); Roman Shpount
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Consensus call on JSEP/ROAP

Hi Richard,

 =

For your first mail on st= andard signaling, I would say that “Welcome to WebRTC signaling”= ;. In fact, I had same expectation of standard signaling as yours 6 months back, Please see WebRTC archive for more details. But, WebRTC (wire= ) signaling protocol will be proprietary per website. The reason for this a= pproach is that there is no need to interop between two different WebRTC si= tes and same  JS (signaling protocol) is executed in all the client within the single website. For example, www.partha.com will have partha protocol and www.richard.com will have Richard protocol wherein partha site and Rich= ard site will never interop with each other. Even if they decide to interop= , it is upto Partha & Richard to decide what is the choice of signaling= protocol and no need of standard at this moment. We may wish to have later  J. Hope this clarifies your doubt on signaling wire protocol.<= span style=3D"color:black">

 =

The aim of WebRTC signali= ng discussion is to verify whether JSEP (WebRTC signaling protocol in API) = defines the basic set of signaling protocol primitives like offer/answer which helps to develop any kind of proprietary/standard proto= col in the wire. So, it is perfectly valid to discuss proprietary SIP callf= low which are prevalent in the deployment in WebRTC mailing list and it wil= l be considered as one WebRTC application.   AFAIK, media protocol (SRTP, ICE) standard are followed in the normal stan= dard fashion as different browsers (like Chrome, IE, Mozilla) and other Web= RTC clients (gateways) has to interop.

 =

As lot of standard SIP im= plementation exists, let us review JSEP in a way that JSEP protocol develop= JS application which helps to interop with standard SIP but it is not the main motive of this group.

 =

Thanks

Partha

 =

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ejzak, Richard P (Richard)
Sent: Wednesday, February 22, 2012 5:11 AM
To: Roman Shpount
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Consensus call on JSEP/ROAP

 =

Hi Roman,

You are correct that parallel = forking is needed to model this case.  I meant to distinguish between = cases where the previous dialog is cleared immediately upon receipt of a new dialog, compared to the case where multiple dialogs are maintaine= d in parallel, and I messed up.  Thanks.

 =

Richard

 =

From: Roman Shpount [mailto:= roman@telurix.com]
Sent: Tuesday, February 21, 2012 5:19 PM
To: Ejzak, Richard P (Richard)
Cc: Cary W FitzGerald; rtcweb@iet= f.org
Subject: Re: [rtcweb] Consensus call on JSEP/ROAP

 =

Hi Richard,

I must apologize as well, since I know that this issue was discussed before= on the list and decision was made to support multiple provisional response= s. I am not sure there was a consensus call on it, but it looked like work = group decided to implement this in both ROAP and JSEP. I see your point about standards, but unfortunately= real life is often different.

You proposal in another thread is only an acceptable compromise if parallel= forking is supported. If parallel forking is supported, each new provision= al SDP can be treated as a new parallel fork and the previous media connect= ion can be discarded.
_____________
Roman Shpount

On Tue, Feb 21, 2012 at = 6:02 PM, Ejzak, Richard P (Richard) <richard.ejzak@alcatel-lucent.com> wrote:=

Hi Roman,

If this issue has already been= debated in the group, I must apologize.  But if standards had to acco= mmodate every non-standard implementation in existence then we wouldn’t be able to accomplish much…

 =

I proposed in another thread t= hat we model this kind of behavior with standard SIP serial forking, which = JSEP must be able to support.  The SIP isn’t exactly the same, but the offer/answer sequence is.  This allows implementations = to realize this flow in practice if necessary without encoding it in our sp= ecs.  Could this be an acceptable compromise?

 =

Richard

 =

From: Roman Shpount [mailto:= roman@telurix.com]
Sent: Tuesday, February 21, 2012 4:32 PM
To: Cary W FitzGerald
Cc: Ejzak, Richard P (Richard); r= tcweb@ietf.org
Subject: Re: [rtcweb] Consensus call on JSEP/ROAP

 =

Another issue is that real-life SIP deployments are often not RFC 32= 64 complaint. In particular it is not unusual to receive different SDP in p= rovisional and final INVITE response. This does not fit offer/answer model since it implies multiple answers to = one offer with subsequent answers overwriting previous ones. So, offer/answ= er compliance is insufficient even for the SIP interop.
_____________
Roman Shpount

On Tue, Feb 21, 2012 at = 3:13 PM, Cary W FitzGerald <ca= ryfitz@employees.org> wrote:

This is partially inevit= able.  For WebRTC applications that interact with SIP gateways, the We= bRTC application can't signal anything that 3264 won't allow, since the gat= eway's side won't be able to deal with it.  The original architecture document http://tools.iet= f.org/html/draft-ietf-rtcweb-overview-02 proposes a RTC trapezoid = and any well-behaved trapezoid needs to consider the SIP case and therefore 3264.

 =

There is another importa= nt case, which is when the trapezoid degenerates into a triangle.  Thi= s is the case where the web server controls both sides of the conversation = (e.g. connecting to an attendant at www.ftd.com without an= y intervening PBX/switch/traditional contact center).  Since there is = no PSTN GW to contend with, it's not necessary to obey the gateway's rules.=  In this case, the server presumably knows what it's doing, so it's probably a bug if it trips itself up.<= /span>

 =

There is potentially a t= hird case, which is where the trapezoid is maintained, and the servers are = communicating with some-protocol-not-SIP that doesn't need to abide by 3264= (which excludes H.323), but are not smart enough to coordinate media between themselves, but this doesn't seem= very important.  I could be wrong about that, but I don't see the pra= ctical use case.

 =

Cary.<= /p>

 =

On Feb 21, 2012, at 8:52= AM, Ejzak, Richard P (Richard) wrote:

 

Hi All,
I would like to point out that if you rephrase the question to ask "wh= o prefers to base subsequent work on RFC 3264 semantics?", then you wo= uld need to combine positions 2 and 4, and you would get a vote of 28 (the = position 3 votes) for a new semantic model (requiring significant new work on SDP) against 21 (the sum of votes for p= ositions 2 and 4) for RFC 3264 semantics.

So while I do not object to using JSEP as a basis for further work, it seem= s that the group is far less certain about the on-the-wire semantics to be = associated with it.  My preference is to focus on RFC 3264 semantics (= noting that the low level of the API would still allow considerable flexibility to support other signaling prot= ocols).  My key concern is to have clear rules (based on common semant= ics) for interworking media/transport negotiation procedures between differ= ent on-the-wire protocols to avoid potential interop problems.  

In particular, at this point in the discussion, I do not see the value of a= llowing multiple open OFFERs within a dialog (which have acknowledged probl= ems), multiple ANSWERs within a dialog, or PRANSWERs, none of which exist i= n RFC 3264.

I propose that the group first decide whether to use JSEP as a basis for fu= rther work and in subsequent step(s) decide whether and how to go beyond RF= C 3264 semantics.  I see this proposal as simply a clarification of th= e meaning of position 3.

Richard Ejzak

-----Original Message-----
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.or= g] On Behalf Of Ted Hardie
Sent: Tuesday, February 07, 2012 2:25 PM
To: rtcweb@ietf.org
Subject: [rtcweb] Consensus call on JSEP/ROAP

During the interim meeting, the attendees discussed the JSEP and ROAP
proposals.  The chairs also asked the working group to consider
whether they might be successfully merged.  Because of audio difficult= ies,
there is no recording available.  The jabber logs contain
a transcription of the discussion by Bernard Aboba and can be found
here: http://www.ietf.org/jabber/logs/rtcweb/2012-01-31.html.

At the end of the discussion, the chairs asked the attendees to
indicate their preferences by standing for one of four positions, which wer= e
listed prior to the question being called.  The positions were:

1--Don't care whether ROAP or JSEP is the input document for further
work in this area

2---Prefer ROAP be the input document for further work

3--Prefer JSEP be the input document for further work

4--Prefer to merge the docs, limiting JSEP to RFC 3264 offer/answer semanti= cs.

The results were: 1=3D9 in room, none in jabber
            &nb= sp;            =    2=3D11 in room, 2 in jabber
            &nb= sp;            =    3=3D25 in room, 3 in jabber
            &nb= sp;            =    4=3D8 in room, none in jabber.

Because JSEP supports more than one model of negotiation, choosing 3
is a reversal  from previous working group consensus to limit work to<= br> the offer/answer model.

The chairs are now calling for consensus of the working group on this
point.  Working group participants who were not present at the interim= ,
please review the input documents if you not have yet done so, and
forward your comments to the list.  All working group participants are=
asked to make
their points on this topic by February 22nd, so that we have timely
input prior to the document deadline for Paris.

thanks,

Ted Hardie for the Chairs
_______________________________________________
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

 =

 =

--_000_387F9047F55E8C42850AD6B3A7A03C6C0E05647Finbamail01sonus_-- From ibc@aliax.net Wed Feb 29 08:14: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 8F18121F86FD for ; Wed, 29 Feb 2012 08:14:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.624 X-Spam-Level: X-Spam-Status: No, score=-2.624 tagged_above=-999 required=5 tests=[AWL=0.053, 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 GdLvvZLPfNit for ; Wed, 29 Feb 2012 08:14:58 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id D2DBC21F8684 for ; Wed, 29 Feb 2012 08:14:57 -0800 (PST) Received: by vcbfk13 with SMTP id fk13so2933802vcb.31 for ; Wed, 29 Feb 2012 08:14:57 -0800 (PST) Received-SPF: pass (google.com: domain of ibc@aliax.net designates 10.52.90.20 as permitted sender) client-ip=10.52.90.20; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ibc@aliax.net designates 10.52.90.20 as permitted sender) smtp.mail=ibc@aliax.net Received: from mr.google.com ([10.52.90.20]) by 10.52.90.20 with SMTP id bs20mr1000556vdb.98.1330532097373 (num_hops = 1); Wed, 29 Feb 2012 08:14:57 -0800 (PST) Received: by 10.52.90.20 with SMTP id bs20mr850436vdb.98.1330532097196; Wed, 29 Feb 2012 08:14:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.156.129 with HTTP; Wed, 29 Feb 2012 08:14:37 -0800 (PST) In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E05647F@inba-mail01.sonusnet.com> References: <6F428EFD2B8C2F49A2FB1317291A76C11355D49DF5@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <005BC7E2-88EE-4D8F-8AEA-4614D39A6DC6@employees.org> <6F428EFD2B8C2F49A2FB1317291A76C11355D4A12E@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <6F428EFD2B8C2F49A2FB1317291A76C11355D4A14E@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <387F9047F55E8C42850AD6B3A7A03C6C0E04CD6A@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804BC2DC3BA@HKGMBOXPRD22.polycom.com> <387F9047F55E8C42850AD6B3A7A03C6C0E05647F@inba-mail01.sonusnet.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 29 Feb 2012 17:14:37 +0100 Message-ID: To: "Ravindran, Parthasarathi" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQn1Y4MuI9u8+OdCHhsi0Na9N9Wl1EAbMW2Gtuckc9exj2dd74KBJJjC2vYtvaHKEhLdqZXh Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consensus call on JSEP/ROAP 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, 29 Feb 2012 16:14:58 -0000 2012/2/29 Ravindran, Parthasarathi : > =C2=A0IMO, SIP over Websocket is a overkill as there is no need of SIP ro= uting > header like via, max-forward, route are not required between webserver an= d > browser. Via header is required to match the transaction. Route headers (or Record-Route) are required to reverse them in responses and play the "loose-routing" game as RFC 3261 states. If the client (the web application running in the web browser) does not handle it, then you need the "web server" to behave as a strange B2BUA doing "protocol conversion" from SIP to YourCustomProtocol and vice versa. You don't like SIP over WebSocket. I like it. It works and it's not an overkill (I do know it, have you tested it?). > The simple protocol mapping between Standard SIP and JSEP will > serve the purpose. Not all the people like protocol gateways. They can just deteriorate the communication, they never improve it. Regards. --=20 I=C3=B1aki Baz Castillo From Ranjit.Avasarala@Polycom.com Wed Feb 29 09:35: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 1012B21F8629 for ; Wed, 29 Feb 2012 09:35:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.782 X-Spam-Level: X-Spam-Status: No, score=-2.782 tagged_above=-999 required=5 tests=[AWL=-1.184, BAYES_00=-2.599, GB_SUMOF=5, 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 Vx5KQawyAArC for ; Wed, 29 Feb 2012 09:35:46 -0800 (PST) Received: from Hkgehubprd01.polycom.com (hkgehubprd01.polycom.com [140.242.6.225]) by ietfa.amsl.com (Postfix) with ESMTP id 3220821F8628 for ; Wed, 29 Feb 2012 09:35:44 -0800 (PST) Received: from hkgmboxprd22.polycom.com ([fe80::c4c3:4566:8b3b:ec85]) by Hkgehubprd01.polycom.com ([fe80::5efe:172.21.6.201%12]) with mapi; Thu, 1 Mar 2012 01:35:43 +0800 From: "Avasarala, Ranjit" To: "Ravindran, Parthasarathi" , "Ejzak, Richard P (Richard)" , Roman Shpount Date: Thu, 1 Mar 2012 01:35:37 +0800 Thread-Topic: [rtcweb] Consensus call on JSEP/ROAP Thread-Index: AQHM5daOqyJlzHkk1UCHKJfTYUstZ5ZHSnCAgAA4QACAACbCgIAACJIAgAAEXACAAAYmAIADtmvggAib2j+AAAIE0IAAM6tQ Message-ID: <1F2A2C70609D9E41844A2126145FC09804BC125072@HKGMBOXPRD22.polycom.com> References: <6F428EFD2B8C2F49A2FB1317291A76C11355D49DF5@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <005BC7E2-88EE-4D8F-8AEA-4614D39A6DC6@employees.org> <6F428EFD2B8C2F49A2FB1317291A76C11355D4A12E@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <6F428EFD2B8C2F49A2FB1317291A76C11355D4A14E@USNAVSXCHMBSA1.ndc.alcatel-lucent.com>, <387F9047F55E8C42850AD6B3A7A03C6C0E04CD6A@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804BC2DC3BA@HKGMBOXPRD22.polycom.com> <387F9047F55E8C42850AD6B3A7A03C6C0E05647F@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E05647F@inba-mail01.sonusnet.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_1F2A2C70609D9E41844A2126145FC09804BC125072HKGMBOXPRD22p_" MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consensus call on JSEP/ROAP 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, 29 Feb 2012 17:35:54 -0000 --_000_1F2A2C70609D9E41844A2126145FC09804BC125072HKGMBOXPRD22p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Partha I do not agree with you when you say SIP over websockets is not required. W= hen websockets is the transport protocol between web browsers and web serve= rs, then it would be signaling protocols like SIP or XMPP that would be use= d for carrying session description information (SDP) - be it ROAP or JSEP d= ata. So be it JSEP/ROAP over SIP or XMPP - these would be over Websockets. So t= hen you need protocol gateways to talk to webservers. This will trigger th= e need for interop between webservers and signaling / media gateways Regards Ranjit From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] Sent: Wednesday, February 29, 2012 9:35 PM To: Avasarala, Ranjit; Ejzak, Richard P (Richard); Roman Shpount Cc: rtcweb@ietf.org Subject: RE: [rtcweb] Consensus call on JSEP/ROAP Hi Ranjit, It depends upon the web servers federation protocol choice. The choices of = federation protocol may be standard protocol like SIP, Jingle or the propr= ietary protocol of site choice. I agree with you that existing VoIP/UC/T= elecom deployments will prefer SIP as a federation protocol but we may not = able to generalize it in RTCWeb. SIP over Websocket is not really required in case JSEP is the choice of bro= wser API protocol. IMO, SIP over Websocket is a overkill as there is no ne= ed of SIP routing header like via, max-forward, route are not required betw= een webserver and browser. The simple protocol mapping between Standard SIP= and JSEP will serve the purpose. Thanks Partha From: Avasarala, Ranjit [mailto:Ranjit.Avasarala@Polycom.com] Sent: Wednesday, February 29, 2012 7:50 PM To: Ravindran, Parthasarathi; Ejzak, Richard P (Richard); Roman Shpount Cc: rtcweb@ietf.org Subject: RE: [rtcweb] Consensus call on JSEP/ROAP Hi Partha I agree with you that websites need not interop with each other and they ca= n have their own proprietary signaling. But the webservers may need to inte= rop and need to support standard signaling protocols to work with other ser= vers like SIP or media servers. so then we need to have some protocol as the default one (E.g. SIP) and if = there is no signaling protocol mentioned, then assume the protocol to be SI= P. I think this is where the draft on SIP over Websockets becomes important wh= en Websockets is used as a transport for carrying signaling messages betwee= n web browsers and web servers. Regards Ranjit ________________________________ From: rtcweb-bounces@ietf.org [rtcweb-bounc= es@ietf.org] On Behalf Of Ravindran, Parthasarathi [pravindran@sonusnet.com= ] Sent: Monday, February 27, 2012 7:51 AM To: Ejzak, Richard P (Richard); Roman Shpount Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Consensus call on JSEP/ROAP Hi Richard, For your first mail on standard signaling, I would say that "Welcome to Web= RTC signaling". In fact, I had same expectation of standard signaling as yo= urs 6 months back, Please see WebRTC archive for more details. But, WebRTC = (wire) signaling protocol will be proprietary per website. The reason for t= his approach is that there is no need to interop between two different WebR= TC sites and same JS (signaling protocol) is executed in all the client wi= thin the single website. For example, www.partha.com= will have partha protocol and www.richard.com will= have Richard protocol wherein partha site and Richard site will never inte= rop with each other. Even if they decide to interop, it is upto Partha & Ri= chard to decide what is the choice of signaling protocol and no need of sta= ndard at this moment. We may wish to have later :). Hope this clarifies yo= ur doubt on signaling wire protocol. The aim of WebRTC signaling discussion is to verify whether JSEP (WebRTC si= gnaling protocol in API) defines the basic set of signaling protocol primit= ives like offer/answer which helps to develop any kind of proprietary/stand= ard protocol in the wire. So, it is perfectly valid to discuss proprietary = SIP callflow which are prevalent in the deployment in WebRTC mailing list a= nd it will be considered as one WebRTC application. AFAIK, media protocol= (SRTP, ICE) standard are followed in the normal standard fashion as differ= ent browsers (like Chrome, IE, Mozilla) and other WebRTC clients (gateways)= has to interop. As lot of standard SIP implementation exists, let us review JSEP in a way t= hat JSEP protocol develop JS application which helps to interop with standa= rd SIP but it is not the main motive of this group. Thanks Partha From: rtcweb-bounces@ietf.org [mailto:rtcwe= b-bounces@ietf.org] On Behalf Of Ejzak, Richard P (Richard) Sent: Wednesday, February 22, 2012 5:11 AM To: Roman Shpount Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Consensus call on JSEP/ROAP Hi Roman, You are correct that parallel forking is needed to model this case. I mean= t to distinguish between cases where the previous dialog is cleared immedia= tely upon receipt of a new dialog, compared to the case where multiple dial= ogs are maintained in parallel, and I messed up. Thanks. Richard ________________________________ From: Roman Shpount [mailto:roman@telurix.com] Sent: Tuesday, February 21, 2012 5:19 PM To: Ejzak, Richard P (Richard) Cc: Cary W FitzGerald; rtcweb@ietf.org Subject: Re: [rtcweb] Consensus call on JSEP/ROAP Hi Richard, I must apologize as well, since I know that this issue was discussed before= on the list and decision was made to support multiple provisional response= s. I am not sure there was a consensus call on it, but it looked like work = group decided to implement this in both ROAP and JSEP. I see your point abo= ut standards, but unfortunately real life is often different. You proposal in another thread is only an acceptable compromise if parallel= forking is supported. If parallel forking is supported, each new provision= al SDP can be treated as a new parallel fork and the previous media connect= ion can be discarded. _____________ Roman Shpount On Tue, Feb 21, 2012 at 6:02 PM, Ejzak, Richard P (Richard) > wrote: Hi Roman, If this issue has already been debated in the group, I must apologize. But= if standards had to accommodate every non-standard implementation in exist= ence then we wouldn't be able to accomplish much... I proposed in another thread that we model this kind of behavior with stand= ard SIP serial forking, which JSEP must be able to support. The SIP isn't = exactly the same, but the offer/answer sequence is. This allows implementa= tions to realize this flow in practice if necessary without encoding it in = our specs. Could this be an acceptable compromise? Richard ________________________________ From: Roman Shpount [mailto:roman@telurix.com] Sent: Tuesday, February 21, 2012 4:32 PM To: Cary W FitzGerald Cc: Ejzak, Richard P (Richard); rtcweb@ietf.org Subject: Re: [rtcweb] Consensus call on JSEP/ROAP Another issue is that real-life SIP deployments are often not RFC 3264 comp= laint. In particular it is not unusual to receive different SDP in provisio= nal and final INVITE response. This does not fit offer/answer model since i= t implies multiple answers to one offer with subsequent answers overwriting= previous ones. So, offer/answer compliance is insufficient even for the SI= P interop. _____________ Roman Shpount On Tue, Feb 21, 2012 at 3:13 PM, Cary W FitzGerald > wrote: This is partially inevitable. For WebRTC applications that interact with S= IP gateways, the WebRTC application can't signal anything that 3264 won't a= llow, since the gateway's side won't be able to deal with it. The original= architecture document http://tools.ietf.org/html/draft-ietf-rtcweb-overvie= w-02 proposes a RTC trapezoid and any well-behaved trapezoid needs to consi= der the SIP case and therefore 3264. There is another important case, which is when the trapezoid degenerates in= to a triangle. This is the case where the web server controls both sides o= f the conversation (e.g. connecting to an attendant at www.ftd.com without any intervening PBX/switch/traditional contact center).= Since there is no PSTN GW to contend with, it's not necessary to obey the= gateway's rules. In this case, the server presumably knows what it's doin= g, so it's probably a bug if it trips itself up. There is potentially a third case, which is where the trapezoid is maintain= ed, and the servers are communicating with some-protocol-not-SIP that doesn= 't need to abide by 3264 (which excludes H.323), but are not smart enough t= o coordinate media between themselves, but this doesn't seem very important= . I could be wrong about that, but I don't see the practical use case. Cary. On Feb 21, 2012, at 8:52 AM, Ejzak, Richard P (Richard) wrote: Hi All, I would like to point out that if you rephrase the question to ask "who pre= fers to base subsequent work on RFC 3264 semantics?", then you would need t= o combine positions 2 and 4, and you would get a vote of 28 (the position 3= votes) for a new semantic model (requiring significant new work on SDP) ag= ainst 21 (the sum of votes for positions 2 and 4) for RFC 3264 semantics. So while I do not object to using JSEP as a basis for further work, it seem= s that the group is far less certain about the on-the-wire semantics to be = associated with it. My preference is to focus on RFC 3264 semantics (notin= g that the low level of the API would still allow considerable flexibility = to support other signaling protocols). My key concern is to have clear rul= es (based on common semantics) for interworking media/transport negotiation= procedures between different on-the-wire protocols to avoid potential inte= rop problems. In particular, at this point in the discussion, I do not see the value of a= llowing multiple open OFFERs within a dialog (which have acknowledged probl= ems), multiple ANSWERs within a dialog, or PRANSWERs, none of which exist i= n RFC 3264. I propose that the group first decide whether to use JSEP as a basis for fu= rther work and in subsequent step(s) decide whether and how to go beyond RF= C 3264 semantics. I see this proposal as simply a clarification of the mea= ning of position 3. Richard Ejzak -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcwe= b-bounces@ietf.org] On Behalf Of Ted Hardie Sent: Tuesday, February 07, 2012 2:25 PM To: rtcweb@ietf.org Subject: [rtcweb] Consensus call on JSEP/ROAP During the interim meeting, the attendees discussed the JSEP and ROAP proposals. The chairs also asked the working group to consider whether they might be successfully merged. Because of audio difficulties, there is no recording available. The jabber logs contain a transcription of the discussion by Bernard Aboba and can be found here: http://www.ietf.org/jabber/logs/rtcweb/2012-01-31.html. At the end of the discussion, the chairs asked the attendees to indicate their preferences by standing for one of four positions, which wer= e listed prior to the question being called. The positions were: 1--Don't care whether ROAP or JSEP is the input document for further work in this area 2---Prefer ROAP be the input document for further work 3--Prefer JSEP be the input document for further work 4--Prefer to merge the docs, limiting JSEP to RFC 3264 offer/answer semanti= cs. The results were: 1=3D9 in room, none in jabber 2=3D11 in room, 2 in jabber 3=3D25 in room, 3 in jabber 4=3D8 in room, none in jabber. Because JSEP supports more than one model of negotiation, choosing 3 is a reversal from previous working group consensus to limit work to the offer/answer model. The chairs are now calling for consensus of the working group on this point. Working group participants who were not present at the interim, please review the input documents if you not have yet done so, and forward your comments to the list. All working group participants are asked to make their points on this topic by February 22nd, so that we have timely input prior to the document deadline for Paris. thanks, Ted Hardie for the Chairs _______________________________________________ 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 --_000_1F2A2C70609D9E41844A2126145FC09804BC125072HKGMBOXPRD22p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Partha

 

I do not agree with you when you say SIP over = websockets is not required. When websockets is the transport protocol betwe= en web browsers and web servers, then it would be signaling protocols like = SIP or XMPP that would be used for carrying session description information= (SDP) – be it ROAP or JSEP data.

 

So b= e it JSEP/ROAP over SIP or XMPP – these would be over Websockets.&nbs= p; So then you need protocol gateways to talk to webservers.  This wil= l trigger the need for interop between webservers and signaling / media gat= eways

 

Regards

Ranjit

 

<= b>From:<= /span> Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com]
Sent: Wednesday, February 29, 2012 9:35 PM
To: Avasarala, Ranjit; Ej= zak, Richard P (Richard); Roman Shpount
Cc: rtcweb@ietf.org
Subject: RE: [rtcweb] Consensus call on JSEP/ROAP

 

Hi Ranjit,

&n= bsp;

It depends upon the web se= rvers federation protocol choice. The choices of federation protocol may be= standard protocol like SIP, Jingle  or the proprietary protocol of si= te choice.    I agree with you that existing VoIP/UC/Telecom= deployments will prefer SIP as a federation protocol but we may not able t= o generalize it in RTCWeb.

 

SIP over Websocket= is not really required in case JSEP is the choice of browser API protocol.=  IMO, SIP over Websocket is a overkill as there is no need of SIP rou= ting header like via, max-forward, route are not required between webserver= and browser. The simple protocol mapping between Standard SIP and JSEP wil= l serve the purpose.

 

Thanks

Partha

 

From: Avasarala, Ranjit [mailto:Ranjit.Avasarala@Polycom.com]
Sent: Wed= nesday, February 29, 2012 7:50 PM
To: Ravindran, Parthasarathi; E= jzak, Richard P (Richard); Roman Shpount
Cc: rtcweb@ietf.org
Subject: RE: [rtcweb] Consensu= s call on JSEP/ROAP

<= o:p> 

Hi Partha

 

I agree with you that websites need not interop with each other and the= y can have their own proprietary signaling. But the webservers may need to = interop and need to support standard signaling protocols to work with other= servers like SIP or media servers.

=

 

so then we nee= d to have some protocol as the default one (E.g. SIP) and if there is no si= gnaling protocol mentioned, then assume the protocol to be SIP.=

 

I think this is where the draft on SIP over Websockets become= s important when Websockets is used as a transport for carrying signaling m= essages between web browsers and web servers.=

 

=

 

=

Regards

Ranjit

 

From: rtcweb-bounces@ietf.org [rtcwe= b-bounces@ietf.org] On Behalf Of Ravindran, Parthasarathi [pravindran@sonus= net.com]
Sent: Monday, February 27, 2012 7:51 AM
To: Ej= zak, Richard P (Richard); Roman Shpount
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Consensus= call on JSEP/ROAP

Hi Richard,

 <= /o:p>

For your first mail on standard= signaling, I would say that “Welcome to WebRTC signaling”. In = fact, I had same expectation of standard signaling as yours 6 months back, = Please see WebRTC archive for more details. But, WebRTC (wire) signaling pr= otocol will be proprietary per website. The reason for this approach is tha= t there is no need to interop between two different WebRTC sites and same&n= bsp; JS (signaling protocol) is executed in all the client within the singl= e website. For example, www.partha.com will have partha protocol and www.richard.com will have Richard protocol = wherein partha site and Richard site will never interop with each other. Ev= en if they decide to interop, it is upto Partha & Richard to decide wha= t is the choice of signaling protocol and no need of standard at this momen= t. We may wish to have later  J. Hope this clarifies yo= ur doubt on signaling wire protocol.

 

The aim of WebRTC signaling= discussion is to verify whether JSEP (WebRTC signaling protocol in API) de= fines the basic set of signaling protocol primitives like offer/answer whic= h helps to develop any kind of proprietary/standard protocol in the wire. S= o, it is perfectly valid to discuss proprietary SIP callflow which are prev= alent in the deployment in WebRTC mailing list and it will be considered as= one WebRTC application.   AFAIK, media protocol (SRTP, ICE) stan= dard are followed in the normal standard fashion as different browsers (lik= e Chrome, IE, Mozilla) and other WebRTC clients (gateways) has to interop. =

 

As lot of standard SIP implementation exists, let us review JSE= P in a way that JSEP protocol develop JS application which helps to interop= with standard SIP but it is not the main motive of this group.

 

Thanks

Partha

 

From: rtcweb-bounces@ietf.org [<= a href=3D"mailto:rtcweb-bounces@ietf.org">mailto:rtcweb-bounces@ietf.org] On Behalf Of Ejzak, Richard P (Richard)
Sent: Wednesday= , February 22, 2012 5:11 AM
To: Roman Shpount
Cc: rtcweb@ietf.org
Subject: Re: [r= tcweb] Consensus call on JSEP/ROAP<= /o:p>

 

Hi Roman,

You are = correct that parallel forking is needed to model this case.  I meant t= o distinguish between cases where the previous dialog is cleared immediatel= y upon receipt of a new dialog, compared to the case where multiple dialogs= are maintained in parallel, and I messed up.  Thanks.

 

Richard=

 

From: Roman Shpount [mailto:roman@telurix.com]
Sent: Tuesday, F= ebruary 21, 2012 5:19 PM
To: Ejzak, Richard P (Richard)
Cc:= Cary W FitzGerald; rtcweb@ietf.org<= /a>
Subject: Re: [rtcweb] Consensus call on JSEP/ROAP

 

Hi Richard,
I must apologize as well, since I know that this issue was discussed befo= re on the list and decision was made to support multiple provisional respon= ses. I am not sure there was a consensus call on it, but it looked like wor= k group decided to implement this in both ROAP and JSEP. I see your point a= bout standards, but unfortunately real life is often different.

You = proposal in another thread is only an acceptable compromise if parallel for= king is supported. If parallel forking is supported, each new provisional S= DP can be treated as a new parallel fork and the previous media connection = can be discarded.
_____________
Roman Shpount<= /span>

On Tue, Feb= 21, 2012 at 6:02 PM, Ejzak, Richard P (Richard) <richard.ejzak@alcatel-lucent.com> wrot= e:

Hi Roman,

If t= his issue has already been debated in the group, I must apologize.  Bu= t if standards had to accommodate every non-standard implementation in exis= tence then we wouldn’t be able to accomplish much…

 

I prop= osed in another thread that we model this kind of behavior with standard SI= P serial forking, which JSEP must be able to support.  The SIP isnR= 17;t exactly the same, but the offer/answer sequence is.  This allows = implementations to realize this flow in practice if necessary without encod= ing it in our specs.  Could this be an acceptable compromise?

 

Ri= chard

 

From: Roman Shpount [mailto:roman@telurix.com]
Sent: Tuesday,= February 21, 2012 4:32 PM
To: Cary W FitzGerald
Cc: Ej= zak, Richard P (Richard); rtcweb@ietf.or= g
Subject: Re: [rtcweb] Consensus call on JSEP/ROAP

 

Ano= ther issue is that real-life SIP deployments are often not RFC 3264 complai= nt. In particular it is not unusual to receive different SDP in provisional= and final INVITE response. This does not fit offer/answer model since it i= mplies multiple answers to one offer with subsequent answers overwriting pr= evious ones. So, offer/answer compliance is insufficient even for the SIP i= nterop.
_____________
Roman Shpount

=

On Tue, Feb 21, 2012 = at 3:13 PM, Cary W FitzGerald <caryfitz@employees.org> wrote:

This is partially inevitable. &nbs= p;For WebRTC applications that interact with SIP gateways, the WebRTC appli= cation can't signal anything that 3264 won't allow, since the gateway's sid= e won't be able to deal with it.  The original architecture document&n= bsp;http://tools.ietf.org/html/draft-ietf-rtcweb-overview-02 proposes a RTC trapezoid and any well-behaved trapezoid needs to con= sider the SIP case and therefore 3264.

=

There is another impo= rtant case, which is when the trapezoid degenerates into a triangle.  = This is the case where the web server controls both sides of the conversati= on (e.g. connecting to an attendant at www.ftd.com without any intervening PBX/switch/traditional= contact center).  Since there is no PSTN GW to contend with, it's not= necessary to obey the gateway's rules.  In this case, the server pres= umably knows what it's doing, so it's probably a bug if it trips itself up.=

 

There is potentially a third case, which is where the t= rapezoid is maintained, and the servers are communicating with some-protoco= l-not-SIP that doesn't need to abide by 3264 (which excludes H.323), but ar= e not smart enough to coordinate media between themselves, but this doesn't= seem very important.  I could be wrong about that, but I don't see th= e practical use case.

 

Cary.

 

=

On Feb 21, 2012,= at 8:52 AM, Ejzak, Richard P (Richard) wrote:

<= p class=3DMsoNormal style=3D'margin-bottom:12.0pt'> 

Hi All,
I would like to point out that if you rephrase the qu= estion to ask "who prefers to base subsequent work on RFC 3264 semanti= cs?", then you would need to combine positions 2 and 4, and you would = get a vote of 28 (the position 3 votes) for a new semantic model (requiring= significant new work on SDP) against 21 (the sum of votes for positions 2 = and 4) for RFC 3264 semantics.

So while I do not object to using JSE= P as a basis for further work, it seems that the group is far less certain = about the on-the-wire semantics to be associated with it.  My preferen= ce is to focus on RFC 3264 semantics (noting that the low level of the API = would still allow considerable flexibility to support other signaling proto= cols).  My key concern is to have clear rules (based on common semanti= cs) for interworking media/transport negotiation procedures between differe= nt on-the-wire protocols to avoid potential interop problems.  
In particular, at this point in the discussion, I do not see the value of = allowing multiple open OFFERs within a dialog (which have acknowledged prob= lems), multiple ANSWERs within a dialog, or PRANSWERs, none of which exist = in RFC 3264.

I propose that the group first decide whether to use JS= EP as a basis for further work and in subsequent step(s) decide whether and= how to go beyond RFC 3264 semantics.  I see this proposal as simply a= clarification of the meaning of position 3.

Richard Ejzak

--= ---Original Message-----
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ted Hardie
Sent: Tuesday= , February 07, 2012 2:25 PM
To: rtcwe= b@ietf.org
Subject: [rtcweb] Consensus call on JSEP/ROAP

Duri= ng the interim meeting, the attendees discussed the JSEP and ROAP
propos= als.  The chairs also asked the working group to consider
whether t= hey might be successfully merged.  Because of audio difficulties,
t= here is no recording available.  The jabber logs contain
a transcri= ption of the discussion by Bernard Aboba and can be found
here: http://www.ietf.org/jabber/logs/rtcweb/2012-01-31.html.

At th= e end of the discussion, the chairs asked the attendees to
indicate thei= r preferences by standing for one of four positions, which were
listed p= rior to the question being called.  The positions were:

1--Don'= t care whether ROAP or JSEP is the input document for further
work in th= is area

2---Prefer ROAP be the input document for further work
3--Prefer JSEP be the input document for further work

4--Prefer to= merge the docs, limiting JSEP to RFC 3264 offer/answer semantics.

T= he results were: 1=3D9 in room, none in jabber
    &= nbsp;           &nbs= p;           2=3D11 = in room, 2 in jabber
        &nb= sp;            =        3=3D25 in room, 3 in jabber
&n= bsp;            = ;            &n= bsp;  4=3D8 in room, none in jabber.

Because JSEP supports= more than one model of negotiation, choosing 3
is a reversal  from= previous working group consensus to limit work to
the offer/answer mode= l.

The chairs are now calling for consensus of the working group on = this
point.  Working group participants who were not present at the= interim,
please review the input documents if you not have yet done so,= and
forward your comments to the list.  All working group particip= ants are
asked to make
their points on this topic by February 22nd, s= o that we have timely
input prior to the document deadline for Paris.
thanks,

Ted Hardie for the Chairs
__________________________= _____________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb=
_______________________________________________
rtcweb mailing l= ist
rtcweb@ietf.org
https://ww= w.ietf.org/mailman/listinfo/rtcweb

 

<= /div>


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

 =

 

=
= --_000_1F2A2C70609D9E41844A2126145FC09804BC125072HKGMBOXPRD22p_-- From hiro.suzuki@d3communications.jp Wed Feb 29 19: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 C9F3521E803E for ; Wed, 29 Feb 2012 19:34:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u+TGmdXitMCF for ; Wed, 29 Feb 2012 19:34:11 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 31B8521E801E for ; Wed, 29 Feb 2012 19:34:10 -0800 (PST) Received: by pbcwz17 with SMTP id wz17so349558pbc.31 for ; Wed, 29 Feb 2012 19:34:10 -0800 (PST) Received-SPF: pass (google.com: domain of hiro.suzuki@d3communications.jp designates 10.68.130.72 as permitted sender) client-ip=10.68.130.72; Authentication-Results: mr.google.com; spf=pass (google.com: domain of hiro.suzuki@d3communications.jp designates 10.68.130.72 as permitted sender) smtp.mail=hiro.suzuki@d3communications.jp; dkim=pass header.i=hiro.suzuki@d3communications.jp Received: from mr.google.com ([10.68.130.72]) by 10.68.130.72 with SMTP id oc8mr14432862pbb.115.1330572850737 (num_hops = 1); Wed, 29 Feb 2012 19:34:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=d3communications.jp; s=google; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=EuiUXYTLnb3nCB1oXucnz0lBhu/UZs/UBoQmai/afQI=; b=l3tfTFVs8OskfGggUY4JmUZItwr+oYgTutvURUeLyN0YrWXpqGwwaCWaVoTh8vJNqB yopKxT7ctvFTpT1zICNPO6PcT4iid6l8288WeKqEJltTA3yhhdL6/Ttl1yWklUChcz2y EdaDGbKc/U+a7VS7ZIw0i5IkUuD6r7IfwHUGk= Received: by 10.68.130.72 with SMTP id oc8mr11946695pbb.115.1330572850689; Wed, 29 Feb 2012 19:34:10 -0800 (PST) Received: from [192.168.1.3] (p8250-ipngn101hodogaya.kanagawa.ocn.ne.jp. [114.158.159.250]) by mx.google.com with ESMTPS id p2sm863852pbb.14.2012.02.29.19.34.09 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 29 Feb 2012 19:34:10 -0800 (PST) From: HIro Suzuki Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 1 Mar 2012 12:34:07 +0900 Message-Id: To: rtcweb@ietf.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQmDh+k4jaEKCbrlRd+ps3oY3pMu8X1P3ewL+7gFw0ZtXsppvzkprVDD0tAjbKmRYhYIndGB Subject: [rtcweb] I'd like to discuss my proposal (jingle-web) at next WG session 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, 01 Mar 2012 03:34:11 -0000 Hello RTCWeb WG members, It's my first post to this ML, and at Feb 28th, I submitted my ID from IETF ID submit tool. This ID's file name is "draft-suzuki-rtcweb-jingle-web-00.txt" and this ID provides my proposal to realize one of solutions of RTCWeb by using XMPP Jingle as a signaling protocol. Following paragraph is abstract of my ID, and I'd like to discuss my proposal at RTCWeb WG session in next Paris meeting. --- Abstract: XMPP Jingle specification defines an XMPP protocol extension for managing peer-to-peer media sessions between two users. And XMPP Jingle can manage multi contents simultaneously in one Jingle stream, but in the XMPP world there is no common way to layout variable multi contents on each display. In this document, a solution to this issue is provided by using Web browser's layout function. This document describes a new concept to realize one of solutions of RTCWeb. Of course, "Web Browser" is used for Web application's frontend for real-time communication, and XMPP Jingle specification (XEP-166) is used as signaling protocol. And a simple mapping manner between jingle contents and HTML graphical elements enables to unite Web browser's layout function and Jingle's media content management function to realize RTCWeb functions. --- Best Regards, Yoshihiro Suzuki (hiro.suzuki@d3communications.jp) From pravindran@sonusnet.com Wed Feb 29 23: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 488E321E803C for ; Wed, 29 Feb 2012 23:00:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GF1hURnPkglr for ; Wed, 29 Feb 2012 23:00:40 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id B3DF721E803B for ; Wed, 29 Feb 2012 23:00:40 -0800 (PST) Received: from sonusmail05.sonusnet.com (sonusmail05.sonusnet.com [10.128.32.155]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q2171PWZ000408; Thu, 1 Mar 2012 02:01:25 -0500 Received: from USMA-EX-HUB2.sonusnet.com ([66.203.90.17]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Mar 2012 01:53:41 -0500 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; Thu, 1 Mar 2012 01:53:43 -0500 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; Thu, 1 Mar 2012 12:23:37 +0530 From: "Ravindran, Parthasarathi" To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Thread-Topic: [rtcweb] Consensus call on JSEP/ROAP Thread-Index: AQHM5daOqyJlzHkk1UCHKJfTYUstZ5ZHSnCAgAA4QACAACbCgIAACJIAgAAEXACAAAYmAIADtmvggAib2j+AAAIE0P//wceAgABceOA= Date: Thu, 1 Mar 2012 06:53:40 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E083267@inba-mail01.sonusnet.com> References: <6F428EFD2B8C2F49A2FB1317291A76C11355D49DF5@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <005BC7E2-88EE-4D8F-8AEA-4614D39A6DC6@employees.org> <6F428EFD2B8C2F49A2FB1317291A76C11355D4A12E@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <6F428EFD2B8C2F49A2FB1317291A76C11355D4A14E@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <387F9047F55E8C42850AD6B3A7A03C6C0E04CD6A@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804BC2DC3BA@HKGMBOXPRD22.polycom.com> <387F9047F55E8C42850AD6B3A7A03C6C0E05647F@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.67] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 01 Mar 2012 06:53:41.0832 (UTC) FILETIME=[09BB7C80:01CCF778] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consensus call on JSEP/ROAP 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, 01 Mar 2012 07:00:41 -0000 SW5ha2ksDQoNCkkgYWdyZWUgdGhhdCB3ZSBoYXZlIHR3byBkaWZmZXJlbnQgYXJjaGl0ZWN0dXJl IGluIG1pbmQuDQoNClJhbmppdC9JbmFraSwNCg0KQWZ0ZXIgSUVURi04MywgSSBjYW4gd3JpdGUg dGhlIGluZm9ybWF0aW9uYWwgbWFwcGluZyBkb2N1bWVudCB0byBzaG93IGhvdyB0byBpbXBsZW1l bnQgc2ltcGxlIHN0YW5kYXJkIFNJUCB1c2luZyBKU0VQLiBMZXQgaW1wbGVtZW50ZXJzIGNob29z ZSB3aGV0aGVyIEpTRVAtU0lQIGdhdGV3YXkgb3IgU0lQIG92ZXIgV2ViU29ja2V0IGlzIHRoZSB3 YXkgdG8gZ28uIA0KDQpUaGFua3MNClBhcnRoYQ0KDQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj5Gcm9tOiBJw7Fha2kgQmF6IENhc3RpbGxvIFttYWlsdG86aWJjQGFsaWF4Lm5ldF0NCj5T ZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDI5LCAyMDEyIDk6NDUgUE0NCj5UbzogUmF2aW5kcmFu LCBQYXJ0aGFzYXJhdGhpDQo+Q2M6IEF2YXNhcmFsYSwgUmFuaml0OyBFanphaywgUmljaGFyZCBQ IChSaWNoYXJkKTsgUm9tYW4gU2hwb3VudDsNCj5ydGN3ZWJAaWV0Zi5vcmcNCj5TdWJqZWN0OiBS ZTogW3J0Y3dlYl0gQ29uc2Vuc3VzIGNhbGwgb24gSlNFUC9ST0FQDQo+DQo+MjAxMi8yLzI5IFJh dmluZHJhbiwgUGFydGhhc2FyYXRoaSA8cHJhdmluZHJhbkBzb251c25ldC5jb20+Og0KPj4gwqBJ TU8sIFNJUCBvdmVyIFdlYnNvY2tldCBpcyBhIG92ZXJraWxsIGFzIHRoZXJlIGlzIG5vIG5lZWQg b2YgU0lQDQo+PiByb3V0aW5nIGhlYWRlciBsaWtlIHZpYSwgbWF4LWZvcndhcmQsIHJvdXRlIGFy ZSBub3QgcmVxdWlyZWQgYmV0d2Vlbg0KPj4gd2Vic2VydmVyIGFuZCBicm93c2VyLg0KPg0KPlZp YSBoZWFkZXIgaXMgcmVxdWlyZWQgdG8gbWF0Y2ggdGhlIHRyYW5zYWN0aW9uLg0KPlJvdXRlIGhl YWRlcnMgKG9yIFJlY29yZC1Sb3V0ZSkgYXJlIHJlcXVpcmVkIHRvIHJldmVyc2UgdGhlbSBpbg0K PnJlc3BvbnNlcyBhbmQgcGxheSB0aGUgImxvb3NlLXJvdXRpbmciIGdhbWUgYXMgUkZDIDMyNjEg c3RhdGVzLiBJZiB0aGUNCj5jbGllbnQgKHRoZSB3ZWIgYXBwbGljYXRpb24gcnVubmluZyBpbiB0 aGUgd2ViIGJyb3dzZXIpIGRvZXMgbm90IGhhbmRsZQ0KPml0LCB0aGVuIHlvdSBuZWVkIHRoZSAi d2ViIHNlcnZlciIgdG8gYmVoYXZlIGFzIGEgc3RyYW5nZSBCMkJVQSBkb2luZw0KPiJwcm90b2Nv bCBjb252ZXJzaW9uIiBmcm9tIFNJUCB0byBZb3VyQ3VzdG9tUHJvdG9jb2wgYW5kIHZpY2UgdmVy c2EuDQo+DQo+WW91IGRvbid0IGxpa2UgU0lQIG92ZXIgV2ViU29ja2V0LiBJIGxpa2UgaXQuIEl0 IHdvcmtzIGFuZCBpdCdzIG5vdCBhbg0KPm92ZXJraWxsIChJIGRvIGtub3cgaXQsIGhhdmUgeW91 IHRlc3RlZCBpdD8pLg0KPg0KPg0KPj4gVGhlIHNpbXBsZSBwcm90b2NvbCBtYXBwaW5nIGJldHdl ZW4gU3RhbmRhcmQgU0lQIGFuZCBKU0VQIHdpbGwgc2VydmUNCj4+IHRoZSBwdXJwb3NlLg0KPg0K Pk5vdCBhbGwgdGhlIHBlb3BsZSBsaWtlIHByb3RvY29sIGdhdGV3YXlzLiBUaGV5IGNhbiBqdXN0 IGRldGVyaW9yYXRlIHRoZQ0KPmNvbW11bmljYXRpb24sIHRoZXkgbmV2ZXIgaW1wcm92ZSBpdC4N Cj4NCj4NCj5SZWdhcmRzLg0KPg0KPg0KPi0tDQo+ScOxYWtpIEJheiBDYXN0aWxsbw0KPjxpYmNA YWxpYXgubmV0Pg0K