rfc8829v2.txt		rfc8829.txt
	skipping to change at line 53 ¶		skipping to change at line 53 ¶
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction		1. Introduction
	1.1. General Design of JSEP		1.1. General Design of JSEP
	1.2. Other Approaches Considered		1.2. Other Approaches Considered
			1.3. Contradiction regarding bundle-only "m=" sections
	2. Terminology		2. Terminology
	3. Semantics and Syntax		3. Semantics and Syntax
	3.1. Signaling Model		3.1. Signaling Model
	3.2. Session Descriptions and State Machine		3.2. Session Descriptions and State Machine
	3.3. Session Description Format		3.3. Session Description Format
	3.4. Session Description Control		3.4. Session Description Control
	3.4.1. RtpTransceivers		3.4.1. RtpTransceivers
	3.4.2. RtpSenders		3.4.2. RtpSenders
	3.4.3. RtpReceivers		3.4.3. RtpReceivers
	3.5. ICE		3.5. ICE
	skipping to change at line 203 ¶		skipping to change at line 204 ¶
	To complete the offer/answer exchange, the remote party uses the		To complete the offer/answer exchange, the remote party uses the
	createAnswer API to generate an appropriate answer, applies it using		createAnswer API to generate an appropriate answer, applies it using
	the setLocalDescription API, and sends the answer back to the		the setLocalDescription API, and sends the answer back to the
	initiator over the signaling channel. When the initiator gets that		initiator over the signaling channel. When the initiator gets that
	answer, it installs it using the setRemoteDescription API, and		answer, it installs it using the setRemoteDescription API, and
	initial setup is complete. This process can be repeated for		initial setup is complete. This process can be repeated for
	additional offer/answer exchanges.		additional offer/answer exchanges.
	Regarding ICE [RFC8445], JSEP decouples the ICE state machine from		Regarding ICE [RFC8445], JSEP decouples the ICE state machine from
	the overall signaling state machine, as the ICE state machine must		the overall signaling state machine. The ICE state machine must
	remain in the JSEP implementation, because only the implementation		remain in the JSEP implementation because only the implementation has
	has the necessary knowledge of candidates and other transport		the necessary knowledge of candidates and other transport
	information. Performing this separation provides additional		information. Performing this separation provides additional
	flexibility in protocols that decouple session descriptions from		flexibility in protocols that decouple session descriptions from
	transport. For instance, in traditional SIP, each offer or answer is		transport. For instance, in traditional SIP, each offer or answer is
	self-contained, including both the session descriptions and the		self-contained, including both the session descriptions and the
	transport information. However, [RFC8840] allows SIP to be used with		transport information. However, [RFC8840] allows SIP to be used with
	Trickle ICE [RFC8838], in which the session description can be sent		Trickle ICE [RFC8838], in which the session description can be sent
	immediately and the transport information can be sent when available.		immediately and the transport information can be sent when available.
	Sending transport information separately can allow for faster ICE and		Sending transport information separately can allow for faster ICE and
	DTLS startup, since ICE checks can start as soon as any transport		DTLS startup, since ICE checks can start as soon as any transport
	information is available rather than waiting for all of it. JSEP's		information is available rather than waiting for all of it. JSEP's
	skipping to change at line 277 ¶		skipping to change at line 278 ¶
	API, which would provide the application with the information it		API, which would provide the application with the information it
	needed in order to generate its own session descriptions. This		needed in order to generate its own session descriptions. This
	increases the amount of work that the application needs to do; it		increases the amount of work that the application needs to do; it
	needs to know how to generate session descriptions from capabilities,		needs to know how to generate session descriptions from capabilities,
	and especially how to generate the correct answer from an arbitrary		and especially how to generate the correct answer from an arbitrary
	offer and the supported capabilities. While this could certainly be		offer and the supported capabilities. While this could certainly be
	addressed by using a library like the one mentioned above, it		addressed by using a library like the one mentioned above, it
	basically forces the use of said library even for a simple example.		basically forces the use of said library even for a simple example.
	Providing createOffer/createAnswer avoids this problem.		Providing createOffer/createAnswer avoids this problem.
			1.3. Contradiction regarding bundle-only "m=" sections
			Since the approval of the WebRTC specification documents, the IETF
			has become aware of an inconsistency between the document specifying
			JSEP and the document specifying BUNDLE (this RFC and [RFC8843],
			respectively). Rather than delaying publication further to come to a
			resolution, the documents are being published as they were originally
			approved. The IETF intends to restart work on these technologies,
			and revised versions of these documents will be published as soon as
			a resolution becomes available.
			The specific issue involves the handling of "m=" sections that are
			designated as bundle-only, as discussed in Section 4.1.1 of this RFC.
			Currently, there is divergence between JSEP and BUNDLE, as well as
			between these specifications and existing browser implementations:
			* JSEP prescribes that said "m=" sections should use port zero and
			add an "a=bundle-only" attribute in initial offers, but not in
			answers or subsequent offers.
			* BUNDLE prescribes that these "m=" sections should be marked as
			described in the previous point, but in all offers and answers.
			* Most current browsers do not mark any "m=" sections with port zero
			and instead use the same port for all bundled "m=" sections; one
			follows the JSEP behavior.
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	3. Semantics and Syntax		3. Semantics and Syntax
	skipping to change at line 394 ¶		skipping to change at line 422 ¶
	session configuration is known. These "resources" can include things		session configuration is known. These "resources" can include things
	like extra ICE components, Traversal Using Relays around NAT (TURN)		like extra ICE components, Traversal Using Relays around NAT (TURN)
	candidates, or video decoders. Provisional answers, on the other		candidates, or video decoders. Provisional answers, on the other
	hand, do no such deallocation; as a result, multiple dissimilar		hand, do no such deallocation; as a result, multiple dissimilar
	provisional answers, with their own codec choices, transport		provisional answers, with their own codec choices, transport
	parameters, etc., can be received and applied during call setup.		parameters, etc., can be received and applied during call setup.
	Note that the final answer itself may be different than any received		Note that the final answer itself may be different than any received
	provisional answers.		provisional answers.
	In [RFC3264], the constraint at the signaling level is that only one		In [RFC3264], the constraint at the signaling level is that only one
	offer can be outstanding for a given session, but at the media stack		offer can be outstanding for a given session, but at the JSEP level,
	level, a new offer can be generated at any point. For example, when		a new offer can be generated at any point. For example, when using
	using SIP for signaling, if one offer is sent and is then canceled		SIP for signaling, if one offer is sent and is then canceled using a
	using a SIP CANCEL, another offer can be generated even though no		SIP CANCEL, another offer can be generated even though no answer was
	answer was received for the first offer. To support this, the JSEP		received for the first offer. To support this, the JSEP media layer
	media layer can provide an offer via the createOffer method whenever		can provide an offer via the createOffer method whenever the
	the JavaScript application needs one for the signaling. The answerer		JavaScript application needs one for the signaling. The answerer can
	can send back zero or more provisional answers and then finally end		send back zero or more provisional answers and then finally end the
	the offer/answer exchange by sending a final answer. The state		offer/answer exchange by sending a final answer. The state machine
	machine for this is as follows:		for this is as follows:
	setRemote(OFFER) setLocal(PRANSWER)		setRemote(OFFER) setLocal(PRANSWER)
	/-----\ /-----\		/-----\ /-----\
	| | | |		| | | |
	v | v |		v | v |
	+---------------+ | +---------------+ |		+---------------+ | +---------------+ |
	| |----/ | |----/		| |----/ | |----/
	| have- | setLocal(PRANSWER) | have- |		| have- | setLocal(PRANSWER) | have- |
	| remote-offer |------------------- >| local-pranswer|		| remote-offer |------------------- >| local-pranswer|
	| | | |		| | | |
	skipping to change at line 759 ¶		skipping to change at line 787 ¶
	codecs supported have the same capabilities, use of a single		codecs supported have the same capabilities, use of a single
	attribute, with the wildcard payload type (*), is RECOMMENDED.		attribute, with the wildcard payload type (*), is RECOMMENDED.
	However, when the supported video codecs have different limitations,		However, when the supported video codecs have different limitations,
	specific "a=imageattr" attributes MUST be inserted for each payload		specific "a=imageattr" attributes MUST be inserted for each payload
	type.		type.
	As an example, consider a system with a multiformat video decoder,		As an example, consider a system with a multiformat video decoder,
	which is capable of decoding any resolution from 48x48 to 720p. In		which is capable of decoding any resolution from 48x48 to 720p. In
	this case, the implementation would generate this attribute:		this case, the implementation would generate this attribute:
	a=imageattr:* recv [x=[48:1280],y=[48:720],q=1.0]		a=imageattr:* recv [x=[48:1280],y=[48:720],q=1.0]
	This declaration indicates that the receiver is capable of decoding		This declaration indicates that the receiver is capable of decoding
	any image resolution from 48x48 up to 1280x720 pixels.		any image resolution from 48x48 up to 1280x720 pixels.
	3.6.2. Interpreting imageattr Attributes		3.6.2. Interpreting imageattr Attributes
	[RFC6236] defines "a=imageattr" to be an advisory field. This means		[RFC6236] defines "a=imageattr" to be an advisory field. This means
	that it does not absolutely constrain the video formats that the		that it does not absolutely constrain the video formats that the
	sender can use but gives an indication of the preferred values.		sender can use but gives an indication of the preferred values.
	skipping to change at line 1211 ¶		skipping to change at line 1239 ¶
	credentials, but it does not change the PeerConnection state, trigger		credentials, but it does not change the PeerConnection state, trigger
	candidate gathering, or cause media to start or stop flowing.		candidate gathering, or cause media to start or stop flowing.
	Specifically, the offer is not applied, and does not become the		Specifically, the offer is not applied, and does not become the
	pending local description, until setLocalDescription is called.		pending local description, until setLocalDescription is called.
	4.1.9. createAnswer		4.1.9. createAnswer
	The createAnswer method generates a blob of SDP that contains an SDP		The createAnswer method generates a blob of SDP that contains an SDP
	answer per [RFC3264] with the supported configuration for the session		answer per [RFC3264] with the supported configuration for the session
	that is compatible with the parameters supplied in the most recent		that is compatible with the parameters supplied in the most recent
	call to setRemoteDescription, which MUST have been called prior to		call to setRemoteDescription; setRemoteDescription MUST have been
	calling createAnswer. Like createOffer, the returned blob contains		called prior to calling createAnswer. Like createOffer, the returned
	descriptions of the media added to this PeerConnection, the		blob contains descriptions of the media added to this PeerConnection,
	codec/RTP/RTCP options negotiated for this session, and any		the codec/RTP/RTCP options negotiated for this session, and any
	candidates that have been gathered by the ICE agent. An options		candidates that have been gathered by the ICE agent. An options
	parameter may be supplied to provide additional control over the		parameter may be supplied to provide additional control over the
	generated answer.		generated answer.
	As an answer, the generated SDP will contain a specific configuration		As an answer, the generated SDP will contain a specific configuration
	that specifies how the media plane should be established; for each		that specifies how the media plane should be established; for each
	SDP line, the generation of the SDP MUST follow the process defined		SDP line, the generation of the SDP MUST follow the process defined
	for generating an answer from the specification that defines the		for generating an answer from the specification that defines the
	given SDP line. The exact handling of answer generation is detailed		given SDP line. The exact handling of answer generation is detailed
	in Section 5.3 below.		in Section 5.3 below.
	skipping to change at line 1522 ¶		skipping to change at line 1550 ¶
	"m=" sections in the specified ICE candidate generation. However, if		"m=" sections in the specified ICE candidate generation. However, if
	both fields are null for a new remote candidate, this MUST be treated		both fields are null for a new remote candidate, this MUST be treated
	as an invalid condition, as specified below.		as an invalid condition, as specified below.
	If any IceCandidate fields contain invalid values or an error occurs		If any IceCandidate fields contain invalid values or an error occurs
	during the processing of the IceCandidate object, the supplied		during the processing of the IceCandidate object, the supplied
	IceCandidate MUST be ignored and an error MUST be returned.		IceCandidate MUST be ignored and an error MUST be returned.
	Otherwise, the new remote candidate or end-of-candidates indication		Otherwise, the new remote candidate or end-of-candidates indication
	is supplied to the ICE agent. In the case of a new remote candidate,		is supplied to the ICE agent. In the case of a new remote candidate,
	connectivity checks will be sent to the new candidate.		connectivity checks will be sent to the new candidate, assuming
			setLocalDescription has already been called to initialize the ICE
			gathering process.
	4.1.20. onicecandidate Event		4.1.20. onicecandidate Event
	The onicecandidate event is dispatched to the application in two		The onicecandidate event is dispatched to the application in two
	situations: (1) when the ICE agent has discovered a new allowed local		situations: (1) when the ICE agent has discovered a new allowed local
	ICE candidate during ICE gathering, as outlined in Section 3.5.1 and		ICE candidate during ICE gathering, as outlined in Section 3.5.1 and
	subject to the restrictions discussed in Section 3.5.3, or (2) when		subject to the restrictions discussed in Section 3.5.3, or (2) when
	an ICE gathering phase completes. The event contains a single		an ICE gathering phase completes. The event contains a single
	IceCandidate object, as defined in Section 3.5.2.1.		IceCandidate object, as defined in Section 3.5.2.1.
	skipping to change at line 1799 ¶		skipping to change at line 1829 ¶
	any stopped RtpTransceivers; this is done in the order the		any stopped RtpTransceivers; this is done in the order the
	RtpTransceivers were added to the PeerConnection. If there are no		RtpTransceivers were added to the PeerConnection. If there are no
	such RtpTransceivers, no "m=" sections are generated; more can be		such RtpTransceivers, no "m=" sections are generated; more can be
	added later, as discussed in [RFC3264], Section 5.		added later, as discussed in [RFC3264], Section 5.
	For each "m=" section generated for an RtpTransceiver, establish a		For each "m=" section generated for an RtpTransceiver, establish a
	mapping between the transceiver and the index of the generated "m="		mapping between the transceiver and the index of the generated "m="
	section.		section.
	Each "m=" section, provided it is not marked as bundle-only, MUST		Each "m=" section, provided it is not marked as bundle-only, MUST
	generate a unique set of ICE credentials and gather its own unique		contain a unique set of ICE credentials and a unique set of ICE
	set of ICE candidates. Bundle-only "m=" sections MUST NOT contain		candidates. Bundle-only "m=" sections MUST NOT contain any ICE
	any ICE credentials and MUST NOT gather any candidates.		credentials and MUST NOT gather any candidates.
	For DTLS, all "m=" sections MUST use any and all certificates that		For DTLS, all "m=" sections MUST use any and all certificates that
	have been specified for the PeerConnection; as a result, they MUST		have been specified for the PeerConnection; as a result, they MUST
	all have the same fingerprint value or values [RFC8122], or these		all have the same fingerprint value or values [RFC8122], or these
	values MUST be session-level attributes.		values MUST be session-level attributes.
	Each "m=" section MUST be generated as specified in [RFC4566],		Each "m=" section MUST be generated as specified in [RFC4566],
	Section 5.14. For the "m=" line itself, the following rules MUST be		Section 5.14. For the "m=" line itself, the following rules MUST be
	followed:		followed:
	skipping to change at line 2358 ¶		skipping to change at line 2388 ¶
	m=audio 20000 UDP/TLS/RTP/SAVPF 0		m=audio 20000 UDP/TLS/RTP/SAVPF 0
	a=mid:a1		a=mid:a1
	a=recvonly		a=recvonly
	m=video 20001 UDP/TLS/RTP/SAVPF 96		m=video 20001 UDP/TLS/RTP/SAVPF 96
	a=mid:v1		a=mid:v1
	a=recvonly		a=recvonly
	The example in Section 7.2 shows a more involved case of "LS" group		The example in Section 7.2 shows a more involved case of "LS" group
	generation.		generation.
	The next step is to generate "m=" sections for each "m=" section that		The next step is to generate an "m=" section for each "m=" section
	is present in the remote offer, as specified in [RFC3264], Section 6.		that is present in the remote offer, as specified in [RFC3264],
	For the purposes of this discussion, any session-level attributes in		Section 6. For the purposes of this discussion, any session-level
	the offer that are also valid as media-level attributes are		attributes in the offer that are also valid as media-level attributes
	considered to be present in each "m=" section. Each offered "m="		are considered to be present in each "m=" section. Each offered "m="
	section will have an associated RtpTransceiver, as described in		section will have an associated RtpTransceiver, as described in
	Section 5.10. If there are more RtpTransceivers than there are "m="		Section 5.10. If there are more RtpTransceivers than there are "m="
	sections, the unmatched RtpTransceivers will need to be associated in		sections, the unmatched RtpTransceivers will need to be associated in
	a subsequent offer.		a subsequent offer.
	For each offered "m=" section, if any of the following conditions are		For each offered "m=" section, if any of the following conditions are
	true, the corresponding "m=" section in the answer MUST be marked as		true, the corresponding "m=" section in the answer MUST be marked as
	rejected by setting the <port> in the "m=" line to zero, as indicated		rejected by setting the <port> in the "m=" line to zero, as indicated
	in [RFC3264], Section 6, and further processing for this "m=" section		in [RFC3264], Section 6, and further processing for this "m=" section
	can be skipped:		can be skipped:
	skipping to change at line 3263 ¶		skipping to change at line 3293 ¶
	the local implementation, enable them on the associated media		the local implementation, enable them on the associated media
	formats.		formats.
	- For any specified "TIAS" ("Transport Independent Application		- For any specified "TIAS" ("Transport Independent Application
	Specific Maximum") bandwidth value, set this value as a		Specific Maximum") bandwidth value, set this value as a
	constraint on the maximum RTP bitrate to be used when sending		constraint on the maximum RTP bitrate to be used when sending
	media, as specified in [RFC3890]. If a "TIAS" value is not		media, as specified in [RFC3890]. If a "TIAS" value is not
	present but an "AS" value is specified, generate a "TIAS" value		present but an "AS" value is specified, generate a "TIAS" value
	using this formula:		using this formula:
	TIAS = AS * 1000 * 0.95 - (50 * 40 * 8)		TIAS = AS * 1000 * 0.95 - (50 * 40 * 8)
	The 1000 changes the unit from kbps to bps (as required by		The 1000 changes the unit from kbps to bps (as required by
	TIAS), and the 0.95 is to allocate 5% to RTCP. An estimate of		TIAS), and the 0.95 is to allocate 5% to RTCP. An estimate of
	header overhead is then subtracted out, in which the 50 is		header overhead is then subtracted out, in which the 50 is
	based on 50 packets per second, the 40 is based on typical		based on 50 packets per second, the 40 is based on typical
	header size (in bytes), and the 8 converts bytes to bits. Note		header size (in bytes), and the 8 converts bytes to bits. Note
	that "TIAS" is preferred over "AS" because it provides more		that "TIAS" is preferred over "AS" because it provides more
	accurate control of bandwidth.		accurate control of bandwidth.
	- For any "RR" or "RS" bandwidth values, handle as specified in		- For any "RR" or "RS" bandwidth values, handle as specified in
	skipping to change at line 3369 ¶		skipping to change at line 3399 ¶
	- If the direction attribute in the answer indicates that the		- If the direction attribute in the answer indicates that the
	JSEP implementation should be sending media ("sendonly" for		JSEP implementation should be sending media ("sendonly" for
	local answers, "recvonly" for remote answers, or "sendrecv" for		local answers, "recvonly" for remote answers, or "sendrecv" for
	either type of answer), choose the media format to send as the		either type of answer), choose the media format to send as the
	most preferred media format from the remote description that is		most preferred media format from the remote description that is
	also locally supported, as discussed in Sections 6.1 and 7 of		also locally supported, as discussed in Sections 6.1 and 7 of
	[RFC3264], and start transmitting RTP media using that format		[RFC3264], and start transmitting RTP media using that format
	once the underlying transport layers have been established. If		once the underlying transport layers have been established. If
	an SSRC has not already been chosen for this outgoing RTP		an SSRC has not already been chosen for this outgoing RTP
	stream, choose a random one. If media is already being		stream, choose a unique random one. If media is already being
	transmitted, the same SSRC SHOULD be used unless the clock rate		transmitted, the same SSRC SHOULD be used unless the clock rate
	of the new codec is different, in which case a new SSRC MUST be		of the new codec is different, in which case a new SSRC MUST be
	chosen, as specified in [RFC7160], Section 4.1.		chosen, as specified in [RFC7160], Section 4.1.
	- The payload type mapping from the remote description is used to		- The payload type mapping from the remote description is used to
	determine payload types for the outgoing RTP streams, including		determine payload types for the outgoing RTP streams, including
	the payload type for the send media format chosen above. Any		the payload type for the send media format chosen above. Any
	RTP header extensions that were negotiated should be included		RTP header extensions that were negotiated should be included
	in the outgoing RTP streams, using the extension mapping from		in the outgoing RTP streams, using the extension mapping from
	the remote description. If the MID header extension has been		the remote description. If the MID header extension has been
	skipping to change at line 3400 ¶		skipping to change at line 3430 ¶
	format in the local description, use silence suppression for		format in the local description, use silence suppression for
	outgoing media, in accordance with the guidance in		outgoing media, in accordance with the guidance in
	Section 5.2.3.2. If these conditions are not met, silence		Section 5.2.3.2. If these conditions are not met, silence
	suppression MUST NOT be used for outgoing media.		suppression MUST NOT be used for outgoing media.
	- If simulcast has been negotiated, send the appropriate number		- If simulcast has been negotiated, send the appropriate number
	of Source RTP Streams as specified in [RFC8853], Section 5.3.3.		of Source RTP Streams as specified in [RFC8853], Section 5.3.3.
	- If the send media format chosen above has a corresponding "rtx"		- If the send media format chosen above has a corresponding "rtx"
	media format or a FEC mechanism has been negotiated, establish		media format or a FEC mechanism has been negotiated, establish
	a redundancy RTP stream with a random SSRC for each Source RTP		a redundancy RTP stream with a unique random SSRC for each
	Stream, and start or continue transmitting RTX/FEC packets as		Source RTP Stream, and start or continue transmitting RTX/FEC
	needed.		packets as needed.
	- If the send media format chosen above has a corresponding "red"		- If the send media format chosen above has a corresponding "red"
	media format of the same clock rate, allow redundant encoding		media format of the same clock rate, allow redundant encoding
	using the specified format for resiliency purposes, as		using the specified format for resiliency purposes, as
	discussed in [RFC8854], Section 3.2. Note that unlike RTX or		discussed in [RFC8854], Section 3.2. Note that unlike RTX or
	FEC media formats, the "red" format is transmitted on the		FEC media formats, the "red" format is transmitted on the
	Source RTP Stream, not the redundancy RTP stream.		Source RTP Stream, not the redundancy RTP stream.
	- Enable the RTCP feedback mechanisms referenced in the media		- Enable the RTCP feedback mechanisms referenced in the media
	section for all Source RTP Streams using the specified media		section for all Source RTP Streams using the specified media
	skipping to change at line 4859 ¶		skipping to change at line 4889 ¶
	Cullen Jennings		Cullen Jennings
	Cisco		Cisco
	400 3rd Avenue SW		400 3rd Avenue SW
	Calgary AB T2P 4H2		Calgary AB T2P 4H2
	Canada		Canada
	Email: fluffy@iii.ca		Email: fluffy@iii.ca
	Eric Rescorla (editor)		Eric Rescorla (editor)
	Mozilla		Mozilla
	331 E. Evelyn Ave.
	Mountain View, CA 94041
	United States of America
	Email: ekr@rtfm.com		Email: ekr@rtfm.com
End of changes. 13 change blocks.
	35 lines changed or deleted		62 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/