Closed Bug 1269486 Opened 8 years ago Closed 8 years ago

ICE role switch when answerer starts renegotiation

Categories

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

defect

Tracking

()

RESOLVED FIXED
mozilla49
Tracking Status
firefox46 --- unaffected
firefox47 --- unaffected
firefox48 --- unaffected
firefox49 --- fixed

People

(Reporter: drno, Assigned: drno)

References

Details

Attachments

(2 files, 2 obsolete files)

test_peerConnection_answererAddSecondAudioStream.html shows that we are switching the ICE roles controlled and controlling after the answerer renegotiated an additional stream.

But RFC 5245 says in section 5.2 https://tools.ietf.org/html/rfc5245#section-5.2
  "Once roles are determined for a session, they persist unless ICE is restarted."
backlog: --- → webrtc/webaudio+
Rank: 10
Attachment #8748087 - Flags: review?(docfaraday)
I'm contemplating if we should also figure out a way to make this SetControlling() call only once:
https://dxr.mozilla.org/mozilla-central/source/media/webrtc/signaling/src/peerconnection/PeerConnectionMedia.cpp#599
Or have SetControlling() internally ignore any call after the initial, first call.

What do you think Byron?
Flags: needinfo?(docfaraday)
Attachment #8748087 - Flags: review?(docfaraday)
Comment on attachment 8748087 [details]
MozReview Request: Bug 1269486: prevent JsepSession from overwritting IceControlling

https://reviewboard.mozilla.org/r/50151/#review47003

::: media/webrtc/signaling/src/jsep/JsepSessionImpl.cpp:1274
(Diff revision 1)
>                                           const UniquePtr<Sdp>& remote)
>  {
>    bool remoteIceLite =
>        remote->GetAttributeList().HasAttribute(SdpAttribute::kIceLiteAttribute);
>  
> +  if (mNegotiations == 0) {

Since this is a rule in the ICE spec, not the JSEP spec, it probably makes sense to push this over to mtransport (right now, this would be NrIceCtx::SetControlling).
Flags: needinfo?(docfaraday)
Attachment #8748087 - Attachment is obsolete: true
Attachment #8748347 - Flags: review?(docfaraday)
Comment on attachment 8748347 [details]
MozReview Request: Bug 1269486: allow setting ICE controller only once. r=bwc

https://reviewboard.mozilla.org/r/50231/#review47065

::: media/mtransport/nricectx.h:374
(Diff revision 1)
>  
>    ConnectionState connection_state_;
>    GatheringState gathering_state_;
>    const std::string name_;
>    bool offerer_;
> +  bool ice_controller_set_;

I'd name this ice_controlling_set_, but yeah this looks good.
Attachment #8748347 - Flags: review?(docfaraday) → review+
Comment on attachment 8748347 [details]
MozReview Request: Bug 1269486: allow setting ICE controller only once. r=bwc

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/50231/diff/1-2/
Attachment #8748347 - Attachment description: MozReview Request: Bug 1269486: allow setting ICE controller only once → MozReview Request: Bug 1269486: allow setting ICE controller only once. r=bwc
Attachment #8748347 - Attachment is obsolete: true
Comment on attachment 8748755 [details]
MozReview Request: Bug 1269486: tests to verify new ICE controller setting restriction. r=mjf

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/50515/diff/1-2/
Comment on attachment 8748769 [details]
MozReview Request: Bug 1269486: allow setting ICE controller only once. r=bwc

https://reviewboard.mozilla.org/r/50525/#review47303

Not sure why rb didn't carry forward my review...
Attachment #8748769 - Flags: review?(docfaraday) → review+
(In reply to Byron Campen [:bwc] (PTO Apr 15) from comment #10)
> Not sure why rb didn't carry forward my review...

Because I followed the suggestion for the hg mozreview plugin and cherry picked the change set with the tests in it. But that wiped out the previous review request completely, including the r+ :-(
Comment on attachment 8748755 [details]
MozReview Request: Bug 1269486: tests to verify new ICE controller setting restriction. r=mjf

https://reviewboard.mozilla.org/r/50515/#review47333

::: media/mtransport/test/ice_unittest.cpp:2623
(Diff revision 2)
> +  ASSERT_EQ(NrIceCtx::ICE_CONTROLLED, p1_->GetControlling());
> +  ASSERT_EQ(NrIceCtx::ICE_CONTROLLING, p2_->GetControlling());
> +
> +  p2_->RestartIce();
> +  ASSERT_FALSE(p2_->gathering_complete());
> +  // ICE restart should allow us to set controll role again

s/controll/control/

::: media/mtransport/test/ice_unittest.cpp:2626
(Diff revision 2)
> +  p2_->RestartIce();
> +  ASSERT_FALSE(p2_->gathering_complete());
> +  // ICE restart should allow us to set controll role again
> +  p2_->SetControlling(NrIceCtx::ICE_CONTROLLED);
> +  ASSERT_EQ(NrIceCtx::ICE_CONTROLLED, p2_->GetControlling());
> +  // But still only allowed to set controll role once

s/controll/control/

::: media/mtransport/test/ice_unittest.cpp:2635
(Diff revision 2)
> +  mozilla::UniquePtr<IceTestPeer> p3_;
> +  p3_ = MakeUnique<IceTestPeer>("P3", test_utils_, true, false,
> +                                false, false, false);
> +  InitPeer(p3_.get());
> +  p3_->AddStream(1);
> +  // Set controll role for p3 accordingly (w/o role conflict)

s/controll/control/
Attachment #8748755 - Flags: review?(mfroman) → review+
Comment on attachment 8748755 [details]
MozReview Request: Bug 1269486: tests to verify new ICE controller setting restriction. r=mjf

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/50515/diff/2-3/
https://hg.mozilla.org/mozilla-central/rev/8d22d6009d64
https://hg.mozilla.org/mozilla-central/rev/3c03f242568d
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla49
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: