Re: [rtcweb] Default candidate pool size

Kiran Kumar Guduru <kiran.guduru@samsung.com> Tue, 13 May 2014 10:30 UTC

Return-Path: <kiran.guduru@samsung.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C97061A000D for <rtcweb@ietfa.amsl.com>; Tue, 13 May 2014 03:30:02 -0700 (PDT)
X-Quarantine-ID: <EK2LHm2mNJ6x>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -5.834
X-Spam-Level:
X-Spam-Status: No, score=-5.834 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_HI=-5, RELAY_IS_203=0.994, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EK2LHm2mNJ6x for <rtcweb@ietfa.amsl.com>; Tue, 13 May 2014 03:29:59 -0700 (PDT)
Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by ietfa.amsl.com (Postfix) with ESMTP id 1319C1A0043 for <rtcweb@ietf.org>; Tue, 13 May 2014 03:29:59 -0700 (PDT)
Received: from epcpsbgr2.samsung.com (u142.gpu120.samsung.co.kr [203.254.230.142]) by mailout2.samsung.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0N5I001END4Z0AE0@mailout2.samsung.com> for rtcweb@ietf.org; Tue, 13 May 2014 19:29:23 +0900 (KST)
Received: from epcpsbgx2.samsung.com ( [172.20.52.126]) by epcpsbgr2.samsung.com (EPCPMTA) with SMTP id C0.7F.14563.304F1735; Tue, 13 May 2014 19:29:23 +0900 (KST)
X-AuditID: cbfee68e-b7fd86d0000038e3-1f-5371f4032ba8
Received: from epmailer03 ( [203.254.219.143]) by epcpsbgx2.samsung.com (EPCPMTA) with SMTP id D3.E0.20075.204F1735; Tue, 13 May 2014 19:29:23 +0900 (KST)
Message-id: <E3.E0.20075.304F1735@epcpsbgx2.samsung.com>
Date: Tue, 13 May 2014 10:29:23 +0000 (GMT)
From: Kiran Kumar Guduru <kiran.guduru@samsung.com>
To: "rtcweb-request@ietf.org" <rtcweb-request@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>, martin.thomson@gmail.com, harald@alvestrand.no
MIME-version: 1.0
X-MTR: 20140513100602076@kiran.guduru
Msgkey: 20140513100602076@kiran.guduru
X-EPLocale: en_US.utf-8
X-Priority: 3
X-EPWebmail-Msg-Type: personal
X-EPWebmail-Reply-Demand: 0
X-EPApproval-Locale:
X-EPHeader: ML
X-EPTrCode:
X-EPTrName:
X-MLAttribute:
X-RootMTR: 20140513100602076@kiran.guduru
X-ParentMTR:
X-ArchiveUser:
X-CPGSPASS: N
MIME-version: 1.0
Content-type: multipart/related; boundary="=_NamoWEC-yk7p1lqr2k"
X-Generator: Namo ActiveSquare 7 7.0.0.45
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJKsWRmVeSWpSXmKPExsWyRsSkTpf5S2GwQetvEYu1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsevLE7aCs2uZKx7vncrUwLhiEXMXIyeHkIC6xIbV99hAbAkB E4lzxx6wQNhiEhfurQeKcwHVLGWUOPWliwWm6E3DGSaIxBxGiccnG8G6eQUsJGbePAo2lUVA VWLmpUNMIDYbUMOvE2sYuxg5OIQFDCVmtoSB9IqA9M58fJsV4golibVXb7JCzBGUODnzCdQy VYn7T2YxQ8TVJE6en80OEReX+NvwCMrmlZjR/hSqXk5i2tc1zBC2tMT5WRsYYb5Z/P0xVJxf 4tjtHUwg94D0PrkfDDNm9+Yv0IAQkJh65iBUq5ZE6813UOP5JNYsfMsCM2bXqeXMML33t8xl Qnc+s4CTxKF1j1khajQlHi1qZQH5XULgAIfE3ddtLBMYlWYh6UFnw/TPAjqVGeiOxbM8IcKK ElO6H7JD2HYSS/5cY8QUV5XYMGMa0wJGjlWMoqkFyQXFSelFRnrFibnFpXnpesn5uZsYgenn 9L9nfTsYbx6wPsRYBYy2icxSosn5wPSVVxJvaGxmZGFqYmpsZG5pRhVhJXHeRQ+TgoQE0hNL UrNTUwtSi+KLSnNSiw8xMnFwSjUw9mfsOnh3SawBD//Rhy8Fk1c+/7/gCcviw0q6faamyQoO bXNP7pVWfhlicHuqV0nyXK7sS3+dI9dc49kk8fqozTHXLZMFNu73lzO4tXVPIaO8VIjTO6NG a+elXFM6eSPn7P+Y/HfnnaOT3u4992LCNFNbh70ba9y7pDxXbejR2y+r2XI+84qfoRJLcUai oRZzUXEiAFiu9rhsAwAA
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCJsWRmVeSWpSXmKPExsVy+t/tfl3mL4XBBqf9LNb+a2d3YPRYsuQn UwBjVJpNRmpiSmqRQmpecn5KZl66rZJ3cLxzvKmZgaGuoaWFuZJCXmJuqq2Si0+ArltmDtBQ JYWyxJxSoFBAYnGxkr6dTVF+aUmqQkZ+cYmtUrShuZGekYGeqZGeoWmslaGBgZEpUE1CWsau L0/YCs6uZa54vHcqUwPjikXMXYycHEIC6hIbVt9jA7ElBEwk3jScYYKwxSQu3FsPFOcCqpnD KPH4ZCNYEYuAqsTMS4fAitiAGn6dWMPYxcjBISxgKDGzJQykXgSkfubj26wQC5Qk1l69CWbz CghKnJz5hAVigarE/SezmCHiahInz89mh4iLS/xteARl80rMaH8KVS8nMe3rGmYIW1ri/KwN jDCHLv7+GCrOL3Hs9g4mkHtAep/cD4YZs3vzF6gfBSSmnjkI1aol0XrzHdR4Pok1C9+ywIzZ dWo5M0zv/S1zmdCdzyzgJHFo3WNWiBpNiUeLWlkmMMrMQlKGzoZpmQV0HTPQ6sWzPCHCihJT uh+yQ9h2Ekv+XGPEFFeV2DBjGtMCRo5VjKKpBckFxUnpFUZ6xYm5xaV56XrJ+bmbGMEJ7dmi HYz/zlsfYhTgYFTi4V3wrCBYiDWxrLgy9xCjCtCcRxtWX2CUYsnLz0tVEuF1/1QYLMSbklhZ lVqUH19UmpNafIhxIiMwkicyS4km5wPTcF5JvKGxibmpsamFgaG5uRkthZXEeeVvJQUJCaQn lqRmp6YWpBbBHMXEwSnVwLh/i3fXk+YXr8M3BW7PirZ7/lqWvXqXxulTOYlsnLfCr0gUXjJ4 P3tmbNMrs41b96ecS3gmHntEeOGXCskbntuFN5j3H7qz/+OqxA5O2bfXuZsreZ61LNDtrl/g U2vo2+fesL7hf/6v3YccD9g/ffzdrql6ikJTX3XsN90g/vr610bG9/a4HldiKc5INNRiLipO BAAHglzr5wMAAA==
DLP-Filter: Pass
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/xgqaSWUdgRlO169MTvr6vJJh6a4
Subject: Re: [rtcweb] Default candidate pool size
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: kiran.guduru@samsung.com
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 May 2014 10:30:03 -0000

Hi All,

As per WebRTC spec,

The localDescription attribute must return the http://dev.w3.org/2011/webrtc/editor/webrtc.html#idl-def-RTCSessionDescription" rel="nofollow">RTCSessionDescription that was most recently passed to http://dev.w3.org/2011/webrtc/editor/webrtc.html#dom-peerconnection-setlocaldescription" rel="nofollow">setLocalDescription(), plus any local candidates that have been generated by the ICE Agent since then.

A null object will be returned if the local description has not yet been set.

 

That is, candidates gathered will be added to SDP, only if localDescription is set (Becuase before setLocalDescription called for first time, localDescription will be NULL).

Now what about the following scenario.

CASE- I

1. createOffer(...)

2. onIceCandidate()

3. setLocalDescription().

 

I agree that setLocalDescription should be called immediately after createOffer, chances always there for receiving a candidate before localDescription is called.

 

How to add this to localDescription?

 

and

CASE-II

1. createOffer(...)

2. setLocalDescription().

3. onIceCandidate()

4. createOffer(...) (with one ice candidate)

5. onIceCandidate()

6. setLocalDescription()(with Once IceCandidate)

 

Should the new setLocalDescription call (with 1 ICE candidate) override the existing localDescription with 2 ICE candidates?

 

 

-------Original Message--------
 Sent: Martin Thomson <martin.thomson@gmail.com>
 Date: Mon, 12 May 2014 11:59:28 -0700
 Subject: Re: [rtcweb] When are ICE candidates added to the SDP

Why not:

1. pc.createOffer(...)

2. success callback fires (0 candidates)

3. pc.setLocalDescription(offer)

4. onicecandidate fires some number of times

5. onicecandidate fires with a null candidate

6. send pc.localDescription (as opposed to the original offer)

No need to run multiple rounds of createOffer or anything nasty like that. Note that we don't have an onicegatheringstatechange event that would let us monitor that state more directly, but the actual code cost is identical either way.

On 12 May 2014 09:14, Harald Alvestrand wrote:

> On 05/12/2014 05:17 PM, Eric Rescorla wrote:

> > > > > On Mon, May 12, 2014 at 6:51 AM, Harald Alvestrand > wrote: >> >> On 05/12/2014 02:39 PM, Eric Rescorla wrote: >> >> >> >> >> On Mon, May 12, 2014 at 2:03 AM, Rauschenbach, Uwe (NSN - DE/Munich) >> wrote: >>> >>> Hi Eric, all, >>> >>> >>> >>> Is the consequence of “always trickle” that ICE candidates have to be >>> added by non-trickling applications via SDP manipulation? >>> >>> I consider this indeed quite inconvenient for non-trickling applications. >> >> >> So, my understanding was that we had agreed that no candidates would >> be available in the first CreateOffer() no matter how many candidates were >> in the pool. >> >> The intent of this message is to ask if that is useful. >> >> >> If an application is written as >> >> 1) CreateOffer() >> 2) wait for the end of candidates callback >> 3) negotiate >> >> then I would think it might have trouble if all the candidates are present >> in the SDP, and therefore no callbacks were called. >> Solution: Always fire the end of candidates callback after calling the >> success callback, even if all candidates are in the SDP already. > > > So you mean: > > 1. CreateOffer() > 2. success callback fires. > 3. SetLocal() > 4. onicecandidate(...) > 5. onicecandidate(null) > > Then later (w/ no changes to the MSTs) > > 6. CreateOffer() > 7. success callback fires > 8. SetLocal (????) > 9. onicecandidate(null) > > I believe this would be a change to the W3C API (not that this is > necessarily bad) > > > Something like that, yes. Or in more detail, for a call requiring 2 > candidates: > > 1. CreateOffer() > 2. success callback fires (1 candidate present) > 3. SetLocal() > 4. onicecandidate(...) > 5. onicecandidate(null) > > Then later (w/ no changes to the MSTs) > > 6. CreateOffer() > 7. success callback fires (2 candidates present) > 8. SetLocal () > 9. onicecandidate(null) > > Then still later (after having done something that requires a 3rd > candidate): > > 10. CreateOffer() > 11. successCallback fires (2 candidates present) > 12. SetLocal() > 13. onicecandidate(...) > 14. onicecandidate(null) > > If we don't have the null onicecandidate in case 2 (step 9), it gets hard to > support case 3 (step 12-14). > > > -Ekr > >> >> >> >> -Ekr >> >>> A way out would be that the SDP always contains the candidates collected >>> so far (as currently defined in the JSEP snippet cited), >>> >>> or that a switch in the API allows an application to configure the >>> behavior when adding ICE candidates. >>> >>> >>> >>> Kind regards, >>> Uwe >>> >>> >>> >>> >>> >>> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of ext Eric >>> Rescorla >>> Sent: Monday, May 12, 2014 8:52 AM >>> To: rtcweb@ietf.org >>> Subject: [rtcweb] When are ICE candidates added to the SDP >>> >>> >>> >>> See: https://github.com/rtcweb-wg/jsep/issues/11 >>> >>> >>> >>> Section 3.4 reads: >>> >>> >>> >>> When a new ICE candidate is available, the ICE Agent will notify the >>> >>> application via a callback; these candidates will automatically be >>> >>> added to the local session description. When all candidates have >>> >>> been gathered, the callback will also be invoked to signal that the >>> >>> gathering process is complete. >>> >>> >>> >>> However, we agreed in London that we would do "always trickle", and >>> >>> that even if there were candidates available at the time when CreateOffer >>> >>> (because of candidate pooling) was called, they would not be included >>> >>> in the initial offer. Consider the following sequence of events. >>> >>> >>> >>> 0. pc = new RTCPeerConnection(); >>> >>> 1. pc.AddStream(stream); >>> >>> 2. pc.CreateOffer(); >>> >>> 3. CreateOffer callback fires with offer A, and you call >>> SetLocalDescription(); >>> >>> 4. onicecandidate fires with candidate X. >>> >>> 5. pc.CreateOffer() >>> >>> 6. CreateOffer callback fires with offer B. >>> >>> 7. onicecandidate fires with null. >>> >>> >>> >>> So, in London, I think we agreed that offer A would have no candidates. >>> >>> The above text implies that if you were to examine localdescription prior >>> >>> to step #5 or at step #7 it would contain candidate X, and probably that >>> offer B would >>> >>> also contain candidate X. >>> >>> >>> >>> Note that it's quite inconvenient for non-trickle applications to never >>> >>> have any candidates in the SDP, especially after gathering is completed >>> >>> at step #7. However it also seems kind of inconsistent to only update the >>> >>> candidates after SetLocal() has been called. >>> >>> >>> >>> -Ekr >>> >>> >> >> >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> >> >> -- >> Surveillance is pervasive. Go Dark. >> >> >> _______________________________________________ >> 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 >
-------Original Message--------
 Sent: "Rauschenbach, Uwe (NSN - DE/Munich)" <uwe.rauschenbach@nsn.com>
 Date: Tue, 13 May 2014 03:44:46 +0000
 Subject: Re: [rtcweb] When are ICE candidates added to the SDP

 

On Mon, May 12, 2014 at 2:03 AM, Rauschenbach, Uwe (NSN - DE/Munich) <uwe.rauschenbach@nsn.com> wrote:

Hi Eric, all,

 

Is the consequence of “always trickle” that ICE candidates have to be added by non-trickling applications via SDP manipulation?

I consider this indeed quite inconvenient for non-trickling applications.

 

So, my understanding was that we had agreed that no candidates would

be available in the first CreateOffer() no matter how many candidates were

in the pool.

 

The intent of this message is to ask if that is useful.

 

-Ekr

 

Thanks for clarifying. As long as the candidates are in the SDP that can be obtained via the API after the “end of candidates”, I think non-trickling applications should be OK.

I was concerned they would not end up in the SDP anymore.

 

-- Uwe

 

A way out would be that the SDP always contains the candidates collected so far (as currently defined in the JSEP snippet cited),

or that a switch in the API allows an application to configure the behavior when adding ICE candidates.

 

Kind regards,
Uwe

 

 

From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of ext Eric Rescorla
Sent: Monday, May 12, 2014 8:52 AM
To: rtcweb@ietf.org
Subject: [rtcweb] When are ICE candidates added to the SDP

 

See: https://github.com/rtcweb-wg/jsep/issues/11" target="_blank" rel="nofollow">https://github.com/rtcweb-wg/jsep/issues/11

 

Section 3.4 reads:

 

When a new ICE candidate is available, the ICE Agent will notify the

application via a callback; these candidates will automatically be

added to the local session description. When all candidates have

been gathered, the callback will also be invoked to signal that the

gathering process is complete.

 

However, we agreed in London that we would do "always trickle", and

that even if there were candidates available at the time when CreateOffer

(because of candidate pooling) was called, they would not be included

in the initial offer. Consider the following sequence of events.

 

0. pc = new RTCPeerConnection();

1. pc.AddStream(stream);

2. pc.CreateOffer();

3. CreateOffer callback fires with offer A, and you call SetLocalDescription();

4. onicecandidate fires with candidate X.

5. pc.CreateOffer()

6. CreateOffer callback fires with offer B.

7. onicecandidate fires with null.

 

So, in London, I think we agreed that offer A would have no candidates.

The above text implies that if you were to examine localdescription prior

to step #5 or at step #7 it would contain candidate X, and probably that offer B would

also contain candidate X.

 

Note that it's quite inconvenient for non-trickle applications to never

have any candidates in the SDP, especially after gathering is completed

at step #7. However it also seems kind of inconsistent to only update the

candidates after SetLocal() has been called.

 

-Ekr

 

 

 

 

 

http://ext.samsung.net/mailcheck/SeenTimeChecker?do=54e220b2ece3918f4a4ffbb30ebdb16d0a462d6a29b517f652ccaaa5e78d7917a586a8c99dfbfbab0edbe683c853fe71db9fdddda33e82cbe4a391424e62fcf6cf878f9a26ce15a0" border="0" width="0" height="0">