RTCPeerConnection: setLocalDescription() method
BaselineWidely available
This feature is well established and works across many devices and browser versions. It’s been available across browsers since September 2017.
ThesetLocalDescription()
method of theRTCPeerConnection
interface changes the local description associated with the connection.This description specifies the properties of the local end of the connection, including the media format.The method takes a single parameter—the session description—and it returns aPromise
which is fulfilled once the description has been changed, asynchronously.
IfsetLocalDescription()
is called while a connection is already in place, it means renegotiation is underway (possibly to adapt to changing network conditions).Because descriptions will be exchanged until the two peers agree on a configuration, the description submitted by callingsetLocalDescription()
does not immediately take effect.Instead, the current connection configuration remains in place until negotiation is complete. Only then does the agreed-upon configuration take effect.
Syntax
setLocalDescription()setLocalDescription(sessionDescription)setLocalDescription(sessionDescription, successCallback, errorCallback) // deprecated
Parameters
sessionDescription
OptionalAn object which specifies the configuration to be applied to the local end of the connection. It should contain the following properties:
type
OptionalA string indicating the type of the session description. If you don't explicitly provide a session description, the WebRTC runtime will try to handle it correctly. If the signaling state is one of
stable
,have-local-offer
, orhave-remote-pranswer
, the WebRTC runtime automatically creates a new offer and sets that as the new local description. Otherwise,setLocalDescription()
creates an answer, which becomes the new local description.sdp
OptionalA string containing the SDP describing the session. If sdp is not provided, it defaults to an empty string. If
type
is"rollback"
,sdp
must be null or an empty string.
If the description is omitted, the WebRTC runtime tries to automatically do the right thing.
You can also pass an actual
RTCSessionDescription
instance, but there's no difference. For this reason, theRTCSessionDescription
constructor is deprecated.
In older code and documentation, you may see a callback-based version of this function used.This has been deprecated and its use isstrongly discouraged, as it will be removed in the future.You should update any existing code to use thePromise
-based version ofsetLocalDescription()
instead.The parameters for the older form ofsetLocalDescription()
are described below, to aid in updating existing code.
successCallback
DeprecatedA JavaScript
Function
which accepts no input parameters to be called once the description has been successfully set.At that time, the offer can be sent to a remote peer via the signaling server.errorCallback
DeprecatedA function matching the signature
RTCPeerConnectionErrorCallback
which gets called if the description can't be set.It is passed a singleDOMException
object explaining why the request failed.
This deprecated form of the method returns instantaneously without waiting for the actual setting to be done: in case of success, thesuccessCallback
will be called; in case of failure, theerrorCallback
will be called.
Return value
APromise
which is fulfilled once the value ofRTCPeerConnection.localDescription
is successfully changed or rejected if the change cannot be applied (for example, if the specified description is incompatible with one or both of the peers on the connection).The promise's fulfillment handler receives no input parameters.
Note:The process of changing descriptions actually involves intermediary steps handled by the WebRTC layer to ensure that an active connection can be changed without losing the connection if the change does not succeed.SeePending and current descriptions in the WebRTC Connectivity page for more details on this process.
Deprecated exceptions
When using the deprecated callback-based version ofsetLocalDescription()
, the following exceptions may occur:
InvalidStateError
DOMException
DeprecatedThrown if the connection's
signalingState
is"closed"
, indicating that the connection is not currently open, so negotiation cannot take place.InvalidSessionDescriptionError
DOMException
DeprecatedThrown if the
sessionDescription
parameter is invalid.
Examples
Implicit descriptions
One of the advantages of the parameter-free form ofsetLocalDescription()
is that it lets you simplify your negotiation code substantially.This is all yournegotiationneeded
event handler needs to look like, for the most part.Just add the signaling server code, which here is represented by the call tosignalRemotePeer()
.
pc.addEventListener("negotiationneeded", async (event) => { await pc.setLocalDescription(); signalRemotePeer({ description: pc.localDescription });});
Other than error handling, that's about it!
Providing your own offer or answer
The example below shows the implementation of a handler for thenegotiationneeded
event that explicitly creates an offer, rather than lettingsetLocalDescription()
do it.
async function handleNegotiationNeededEvent() { try { const offer = await pc.createOffer(); pc.setLocalDescription(offer); signalRemotePeer({ description: pc.localDescription }); } catch (err) { window.reportError(err); }}
This begins by creating an offer by callingcreateOffer()
; when that succeeds, we callsetLocalDescription()
.We can then send the newly-created offer along to the other peer using the signaling server, which here is done by calling a functioncalledsignalRemotePeer()
.
Specifications
Specification |
---|
WebRTC: Real-Time Communication in Browsers # dom-peerconnection-setlocaldescription |