New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 8 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

Half-trickle ICE offer does not contain an a=end-of-candidates attribute.

Reported by frankcoc...@gmail.com, Sep 2 2014 Back to list

Issue description

What steps will reproduce the problem?
1.Make a chrome (half-trickle) to chrome (full trickle-ice) audio/video call.
2.The initial offer from the caller contains ICE candidates and the a=ice-options:trickle attribute, but does not include an "a=end-of-candidates" attribute.
3.

What is the expected result?
Per draft-ietf-mmusic-trickle-ice-01 draft "Trickle ICE: Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Proctocol", section 4.1 Unilateral Use of Trickle ICE states:
"half is about having the caller sned a regular vanilla ICE offer, with a complete set of candidates. Half trickle offers will typically contain an end-of-candidates indication".

I understand the wording of this draft states "typically", but Chrome should include the end-of-candidates attribute when "half" trickle ICE is used to indicate the harvesting of candidates has completed and that the offer contains a full list of candidates.


What do you see instead?
The does not send an "a=end-of-candidates" attribute in its offer. Without the end-of-candidates attribute it is difficult to determine if the offer can be treated as a vanilla ice offer or as an initial trickle ICE offere (i.e. with more candidates to follow).


What version of the product are you using? On what operating system?
Chrome version Version 37.0.2062.102 m
Windows 7 Professional


Please provide any additional information below.
Attaching the caller and callee browser console logs.





 
caller_browser_console.txt
28.1 KB View Download
callee_browser_console.txt
30.0 KB View Download
Project Member

Comment 1 by braveyao@webrtc.org, Sep 3 2014

Cc: jiayl@webrtc.org braveyao@webrtc.org vikasmarwaha@webrtc.org
Owner: juberti@webrtc.org
I'm not sure whether this draft is still valid or not. Nor found anything in the source too.

@justin, please help to comment!
Project Member

Comment 2 by juberti@webrtc.org, Sep 3 2014

Labels: Area-PeerConnection
Status: Available
Yes, this description is correct. See https://github.com/rtcweb-wg/jsep/issues/80 for the details that we have decided.

Comment 3 by vrk@webrtc.org, Oct 16 2014

Labels: Mstone-41 EngTriaged
Tentatively put to M41. Justin, feel free to adjust prio.
Project Member

Comment 4 by pthatcher@webrtc.org, Jan 7 2015

Labels: -Mstone-41 Mstone-42
Project Member

Comment 5 by pthatcher@webrtc.org, Feb 19 2015

Labels: -Mstone-42 Mstone-44
This looks like it's not hitting m42.  Update it if I'm wrong.
Project Member

Comment 6 by tnakamura@webrtc.org, Jan 29 2016

Cc: -vikasmarwaha@webrtc.org
Labels: -Mstone-44
I don't see any recent CLs linked to this bug, so I don't think it's been fixed. I'm therefore leaving this in an open state, but I am removing the milestone label since this bug hasn't been updated in quite some time.
Project Member

Comment 7 by pthatcher@webrtc.org, Nov 8 2016

Labels: Pri-3
Project Member

Comment 8 by anatolid@webrtc.org, Dec 14 2016

Cc: juberti@webrtc.org
Owner: ----

Sign in to add a comment