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

Issue 4127 link

Starred by 6 users

Issue metadata

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

Sign in to add a comment

muxed prflx port cxns created by cricket::P2PTransportChannel::OnUnknownAddress not always added to cricket::P2PTransportChannel::connections_

Reported by, Dec 28 2014

Issue description

What steps will reproduce the problem?
1. initiate session (i.e. send a/v/d sdp offer) to ffox 34.0 via

What is the expected result?
sdp offer/answer(s) and ice candidate(s) exchanged and session established.

What do you see instead?
only audio p2p cxn established and hosting app crashes on assert (using debug bits) after first video cxn timeout:

Jingle:Conn[0x7f07ecdd0db0:audio:n3zOpK+B:1:0:local:udp:>|C--I|7241788200761179647|-]: Timed out after 15006 ms without a response, rtt=3000
Jingle:Conn[0x7f07ecdd0db0:audio:n3zOpK+B:1:0:local:udp:>|C-xI|7241788200761179647|-]: Connection deleted due to read or write timeout
Jingle:Channel[video|1|__]: Removed connection (0 remaining)
Jingle:Channel[video|1|__]: No best connection
Error( ../../talk/app/webrtc/ ASSERT FAILED: state == PeerConnectionInterface::kIceConnectionDisconnected || state == PeerConnectionInterface::kIceConnectionChecking || state == PeerConnectionInterface::kIceConnectionCompleted @ SetIceConnectionState 

What version of the product are you using? On what operating system?
Linux xxxxxxx 3.13.0-43-generic #72-Ubuntu SMP Mon Dec 8 19:35:06 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

Please provide any additional information below.
this seems time sensitive (race-condition) but consistently happened ~ 1/3 of the time when testing interop w/ ffox 34.0 on a local connection. the situation is:

- port is mux'd (i.e. shared between media/data channels).
- ice_candidates for cxns delayed until *after* stun messages on the port are recv'd.
- ``known_username`` in cricket::P2PTransportChannel::OnUnknownAddress is ``false`` for other mux'd channels.

in which case:

- a prflx connection is created for the port and added to only one of target cricket::P2PTransportChannel assoc'd w/ the port:

Jingle:Channel[audio|1|RW]: Created connection with origin=2, (3 total)

but not others:

Jingle:Channel[video|1|__]: Created connection with origin=2, (1 total)

later when delayed ice candidates for targeted channels are recv'd they fail equivalence checks in cricket::P2PTransportChannel::CreateConnection:

Attempt to change a remote candidate. Existing remote candidate: Cand[2600897032:1:udp:1853817087:]New remote candidate: Cand[0:1:udp:2122252543:]

and are *not* added to cricket::P2PTransportChannel::connections_. attached patch:

1. adds the existing port connection using cricket::P2PTransportChannel::AddConnection.
2. notes possible problem with candidate equivalence check.

and session est is successful even in this situation.

1.4 KB Download
Project Member

Comment 1 by, Dec 29 2014

Labels: Area-Network
@aab112233, some questions:
- what does "port is mux'd (i.e. shared between media/data channels)." mean? AFAICT, FF doesn't support Muxing/Bundle yet.
- Does this only happen to interacting with FF?
- Are the three issues, issue4127, issue4126 and  issue4125 , separate issues or related?

@jiay, please help to check this one too.
Project Member

Comment 2 by, Dec 29 2014

Status: unconfirmed
This should go away with

Comment 3 by, Dec 29 2014


- not sure i use the right terms here but for "port is mux'd" i mean multiple channels (audio, video, data) use the same port.
- yes, only able to repro this when interop w/ ffox (e.g. *not* chrome, icelink, etc).
- these ones are minor things i notice, maybe not important to fix so i left them separate in case you want to just ignore/wont-fix it. this is the only issue that caused functional problem.

Project Member

Comment 4 by, Dec 29 2014

Labels: EngTriaged
Jiayang, can you mark this fixed if you submitted a fix?
Project Member

Comment 5 by, Dec 29 2014,

Could you check if the issue is fixed on head of Trunk?
Project Member

Comment 6 by, Nov 8 2016

Labels: Pri-3
Project Member

Comment 7 by, Dec 5 2016

Status: Assigned (was: Unconfirmed)
[bulk-edit] This issue appears to have been triaged (as evidenced by the presence of the EngTriaged label) and also has an Owner -- hence, changing its status to Assigned. If the currently set Owner is wrong, then please re-assign to a correct Owner, or remove Owner and set status to Available.
Project Member

Comment 8 by, Apr 3 2018

Owner: ----
Status: Available (was: Assigned)
Clearing owner and setting status to Available, since there haven't been any updates for > 1 year. Will be assigned again once priority is high enough.

Sign in to add a comment