Open Bug 1018791 Opened 9 years ago Updated 5 years ago

Implement W3C Codec reservation semantics for CreateOffer and CreateAnswer


(Core :: WebRTC: Signaling, defect, P5)





(Reporter: jesup, Unassigned)


(Blocks 1 open bug)


(Follow-on to bug 1003712)

The W3 specs for JSEP say that a codec reservation exists from CreateOffer's success callback until the callback returns, and in that time if the offer/answer was not installed with SetLocalDescription, then any reservation is void (you can be able to SetLocalDescription later successfully, but you also might find that someone else has grabbed the hardware and cause SetLocalDescription to fail).  

For example, if you delay SetLocalDescription, another call could grab the hardware, or even a streaming video playback.

Note that any reservation must be shared/used by the HW codecs, or we must have it always handled in a higher layer (such as the JSEP/etc/SIPCC and/or PCMedia layer).  Also note it must not be released why reconfiguring codecs, and the code will (itself) shot down and create new codecs to replace the current ones, so locking in the codec itself may be error-prone.

The current patches on bug 1003713 implement a simplified version that checks if the codec is in use at CreateOffer/Answer time, and assumes the codec itself gets reservations at InitEncode/Decode time.
Note: handling the full W3 semantics around reservations is not needed for FxOS 2.0.
(In reply to Randell Jesup [:jesup] from comment #0)
> The current patches on bug ...

Looks like you mean Bug 1003712.
Pulled from the SIPCC patch there:
  // We should create and hold a reservation which is tied to the offer/answer being
  // created, and then release that reservation at the end of CreateOffer's/Answer's
  // success callback.  If during the callback the SDP is installed, transfer the
  // reservation, such that no other CreateOffer/Answer can use the the codec.  When
  // the call actually starts, use the reservation but ensure it's held during reconfigs
  // like when the resolution changes, which implies it should not be held in the actual
  // encoder/decoder, but in call control, or PCImpl/Media/etc.
Blocks: webrtc_spec
backlog: --- → webRTC+
Rank: 45
Priority: -- → P4
Mass change P4->P5 to align with new Mozilla triage process.
Priority: P4 → P5
You need to log in before you can comment on or make changes to this bug.