Question: In an MRFC-MRFP interface using TCP as transport protocol, how does the MRFC determine whether the MRFP should act as TCP client or server when receiving an SDP offer for a new TCP-based media stream?
Option 1: Based on the 'a=connection' SDP attribute in the SDP offer.
Option 2: By sending a separate control message to the MRFP to explicitly specify its role.
Option 3: Via SDP negotiation using the IETF RFC 4145 'a=setup' SDP attribute (e.g., 'a=setup:active' or 'a=setup:passive').
Option 4: Automatically, with the MRFP always acting as TCP server for incoming media streams.
Explanation: The role of the MRFP is determined through SDP negotiation, specifically by examining the 'a=setup' SDP attribute in the SDP offer or answer, where attributes like 'a=setup:active' and 'a=setup:passive' dictate whether the MRFP should initiate (client) or wait for (server) a TCP connection, aligning with standardized communication setup.