1208254 - ICE Triggered Checks retransmit instead of starting new transactions

Status: RESOLVED DUPLICATE of bug 1006809

(Core :: WebRTC: Networking, defect, P1)

Description

[Nils Ohlmeier [:drno]]

According to https://tools.ietf.org/html/rfc5245#section-7.2.1.4 bullet point 1.2 we are suppose to cancel ongoing STUN transactions and start a new one.

It looks like we are canceling the ongoing STUN transaction here https://dxr.mozilla.org/mozilla-central/source/media/mtransport/third_party/nICEr/src/stun/stun_client_ctx.c?offset=1000#284

But on the wire the new binding request has the same transaction ID as the previous.

Comment 1

[Nils Ohlmeier [:drno]]

Attachment: MozReview Request: Bug 1208254: (re)start a new ICE binding request trnasaction for triggered checks

Bug 1208254: (re)start a new ICE binding request trnasaction for triggered checks

Comment 2

[Nils Ohlmeier [:drno]]

FYI without this patch we fail to connect to Cisco Spark, because the calls to nr_stun_client_force_retransmit() counts the retransmits towards the retransmission counters, which happens to be 1 for ICE TCP. This fixes that issue, because sending a new binding request does not count towards the transmission counter, which seems to be right thing any how.
I'm just not 100% sure if this change could lead to other bad side effects.

Comment 3

[Nils Ohlmeier [:drno]]

Comment on attachment 8672837 [details]
MozReview Request: Bug 1208254: (re)start a new ICE binding request trnasaction for triggered checks

Apparently this is a bad idea/solution

Comment 4

[Nils Ohlmeier [:drno]]

This basically got fixed through the code landed in bug 1006809.