Skip to main content

5.2.1. Initial Offers

5.2.1. Initial Offers​

When createOffer is called for the first time, the result is known as the initial offer.

The first step in generating an initial offer is to generate session-level attributes, as specified in [RFC4566], Section 5. Specifically:

  • The first SDP line MUST be "v=0" as defined in [RFC4566], Section 5.1.

  • The second SDP line MUST be an "o=" line as defined in [RFC4566], Section 5.2. The value of the <username> field SHOULD be "-". The <sess-id> MUST be representable by a 64-bit signed integer, and the value MUST be less than 2^(63)-1. It is RECOMMENDED that the <sess-id> be constructed by generating a 64-bit quantity with the highest bit set to zero and the remaining 63 bits being cryptographically random. The value of the <nettype> <addrtype> <unicast-address> tuple SHOULD be set to a non-meaningful address, such as IN IP4 0.0.0.0, to prevent leaking a local IP address in this field; this problem is discussed in [RFC8828]. As mentioned in [RFC4566], the entire "o=" line needs to be unique, but selecting a random number for <sess-id> is sufficient to accomplish this.

  • The third SDP line MUST be a "s=" line as defined in [RFC4566], Section 5.3; to match the "o=" line, a single dash SHOULD be used as the session name, e.g., "s=-". Note that this differs from the advice in [RFC4566], which proposes a single space, but as both "o=" and "s=" are meaningless in JSEP, having the same meaningless value seems clearer.

  • Session Information ("i="), URI ("u="), Email Address ("e="), Phone Number ("p="), Repeat Times ("r="), and Time Zones ("z=") lines are not useful in this context and SHOULD NOT be included.

  • Encryption Keys ("k=") lines do not provide sufficient security and MUST NOT be included.

  • A "t=" line MUST be added, as specified in [RFC4566], Section 5.9; both <start-time> and <stop-time> SHOULD be set to zero, e.g., "t=0 0".

  • An "a=ice-options" line with the "trickle" and "ice2" options MUST be added, as specified in [RFC8840], Section 4.1.1 and [RFC8445], Section 10.

  • If WebRTC identity is being used, an "a=identity" line MUST be added, as described in [RFC8827], Section 5.

The next step is to generate "m=" sections, as specified in [RFC4566], Section 5.14. An "m=" section is generated for each RtpTransceiver that has been added to the PeerConnection, excluding any stopped RtpTransceivers; this is done in the order the RtpTransceivers were added to the PeerConnection.

Each "m=" section, provided it is not marked as bundle-only, MUST contain a unique set of ICE credentials and a unique set of ICE candidates. Bundle-only "m=" sections MUST NOT contain any ICE credentials and MUST NOT gather any candidates.

For DTLS, all "m=" sections MUST use any and all certificates that have been specified for the PeerConnection; as a result, they MUST all have the same fingerprint value or values [RFC8122], or these values MUST be session-level attributes.

Last updated on