Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
This section specifies common rules that apply to handling application sharing specific SDP offers or answers within the MCU entity. The rules specified in this section assume that the correlation relationships between SDP media instances and user media instances have been established.
The following conceptual steps specify the requirements for processing a received SDP offer.
For each SDP media instance that is correlated with a user media instance:
§ If the SDP offer specifies that a previously negotiated media stream has been removed, as specified in [RFC3264] section 8.2, the MCU MUST omit the user media instance from subsequent MCU Roster (user) notifications.
§ If the SDP offer specifies that a previously rejected or removed media stream has been re-instantiated using the same SDP media "slot", as specified in [RFC3264] section 8.1, the MCU MUST include the user media instance in subsequent MCU Roster (user) notifications and continue.
§ The MCU MUST determine the value of the status element in the media element in the user notification by analyzing the offered SDP direction attribute, a=x-applicationsharing-role. If the SDP direction attribute is "sharer", the status element MUST be set to "sendonly". If the attribute is "viewer", the element MUST be set to "recvonly".
§ If the media capabilities of the implementation do not support the parameters of the offered media instance, the MCU MUST reject the media instance using the conventional "port=0" semantics specified in [RFC3264] section 8.1.
§ When constructing the SDP answer for this media instance, the MCU MUST specify the "reverse" direction for media flow. For example, if the SDP offer is received with an attribute a=x-applicationsharing-role with the value "sharer", the MCU responds with a direction of a=x-applicationsharing-role with the value "viewer".
§ When constructing the SDP answer for this media instance, the MCU MUST specify the session-id that the protocol client is joining in the a=x-applicationsharing-session-id field.
§ If the offered media instance has more than one m= line for "sharing" or more than one m= line for "viewing", the offer MUST be rejected entirely.
§ If the resulting SDP answer would reject all offered media instances, the MCU MUST respond to the INVITE message with a SIP 488 Reason Code with a "Not Acceptable Here" reason phrase and do no further processing.
§ The remainder of the SDP media description (m line) follows the specifications in [MS-SDPEXT] section 1.3, and is beyond the scope of this specification.
§ If the SDP offer does not contain any active video line, the MCU SHOULD<8> send an SDP offer to all other participants in the call, declining Video-based Screen Sharing with conventional "port=0" semantics specified in [RFC3264] and omitting the x-applicationsharing-contentflow attribute from the RDP media channel.