1018791 - Implement W3C Codec reservation semantics for CreateOffer and CreateAnswer

Status: NEW

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

Description

[Randell Jesup [:jesup] (needinfo me)]

(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 webrtc.org 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.

Comment 1

[Randell Jesup [:jesup] (needinfo me)]

Note: handling the full W3 semantics around reservations is not needed for FxOS 2.0.

Comment 2

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

(In reply to Randell Jesup [:jesup] from comment #0)
> The current patches on bug ...

Looks like you mean Bug 1003712.

Comment 3

[Randell Jesup [:jesup] (needinfo me)]

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.

Comment 4

[Bulk Bug Changes for mreavy's org]

Mass change P4->P5 to align with new Mozilla triage process.