W3C home > Mailing lists > Public > public-webrtc@w3.org > December 2012

RE: SDP <sess-version> element and Trickle Ice

From: Suhas Nandakumar (snandaku) <snandaku@cisco.com>
Date: Mon, 17 Dec 2012 20:13:01 +0000
To: Christer Holmberg <christer.holmberg@ericsson.com>, Adam Roach <adam@nostrum.com>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <37D91FC30D69DE43B61E5EEADD959F1807C14923@xmb-aln-x12.cisco.com>

From: Christer Holmberg [christer.holmberg@ericsson.com]
Sent: Monday, December 17, 2012 11:43 AM
To: Adam Roach
Cc: public-webrtc@w3.org
Subject: RE: SDP <sess-version> element and Trickle Ice


>>> If we are changing the sess-version of localDescription because we've added that candidate, then the smallest increase possible would be to change sess-version to 2.
>>> Now, imagine that the remote party, at some point in the future, sent us a new offer with a sess-version of 2.
>> Maybe I'm missunderstanding the issue, but don't we have that issue already today, without trickle ICE?
>> Assume I send you an SDP offer, with candidates A, B and C, and sess-version 1. No trickle ICE - pure good old legacy ICE.
>> Later, you receive a STUN reuqest which generates a peer-relexive candidate, candidate D, from me. You will now update your candidate list etc, but I don't think you are going to update the sess-version in the SDP offer I previously sent you.
> Let's back up for a second. You are *familiar* with the remoteDescription attribute on the PeerConnection class, yes?

Yes. It returns the previously stored remote description, and any additional candidate(s) that have been added later.

And, to verify that I understand the issue correctly: the question is whether, whenever I add a candidate to the stored remote description, the sess-version should be incremented.

One question (my appologies if I've missed it in the trickle ICE discussion): whenever a new SDP offer IS received (for whatever reasons), will it also contain the trickle candidates that were not present in the previous SDP offer, but were later conveyed using some other mechanism?

I don't think a new SDP will be generated for the peer-reflexive candidates. On discovering a candidate that seems to be a peer-reflexive-candidate as a result of the STUN procedure, such a candidate is added to its local media-stream on either side. This way both the peers discover these candidates individually and update their candidate list respectively. Then kicks in the process of generating valid pairs by systematically trying out all the candidates


Received on Monday, 17 December 2012 20:13:32 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:32 UTC