Common use of TIP Negotiation Clause in Contracts

TIP Negotiation. This section describes how an implementation detects that its remote peer is capable of understanding TIP. If the remote peer does not implement TIP, an implementation SHOULD operate in a strictly standards compliant mode where only a single audio or video stream is sent in the media channel, and no TIP specific control extensions are used. TIP uses the RTCP extension mechanism, the APP packet, which allows for private uses to signal all of its control information. TIP uses the RTCP private application name “xcts” ,eXtended Control for Telepresence Systems, for all of its control packets. TIP defines an RTCP APP MUXCTRL packet which informs the remote peer of media multiplexing capabilities. This includes the number of media streams that a device is willing to transmit and willing to receive for a given media channel of a particular type (audio or video). It also allows the receiver to specify which media positions it is willing to transmit and receive. The reception of an RTCP APP MUXCTRL packet or an RTCP APP MUXCTRL ACK packet specifying the TIP private application name, “xcts”, is used as acknowledgement that TIP is understood by the remote peer. TIP requires that the local system’s MUXCTRL be acknowledged by the remote peer and that the MUXCTRL of the remote peer be received before communication under the rules of TIP can begin. The RTCP APP packets and processing rules are detailed in section 4.2 The TIP negotiation begins by sending the RTCP APP MUXCTRL on the RTCP UDP channel(s) indicated by the media channel establishment. For a short interval (recommendation is 15 seconds), the MUXCTRL packet should be periodically retransmitted, until an acknowledgement is received or the interval elapses without a response. The reception of either a MUXCTRL or MUXCTRL ACK packet on the RTCP UDP channel SHOULD be interpreted as support of TIP. An implementation SHOULD acknowledge all MUXCTRL packets it receives. The lack of any response MUST be interpreted as a lack of support for TIP, and hence the standard RTCP traffic should be sent on the RTCP UDP channel as per the standard mode of operation for [4], unless the peer has signaled otherwise in SDP [9].

TIP Negotiation. This section describes how an implementation detects that its remote peer is capable of understanding TIP. If the remote peer does not implement TIP, an implementation SHOULD operate in a strictly standards compliant mode where only a single audio or video stream is sent in the media channel, and no TIP specific control extensions are used. TIP uses the RTCP extension mechanism, the APP packet, which is an extension of RTCP and allows for private uses control information to signal all of its control informationbe transmitted. . TIP uses the RTCP private application name “xcts” ,”, eXtended Control for Telepresence Systems, for all of its control packets. TIP defines an RTCP APP MUXCTRL packet which informs the remote peer of about media multiplexing capabilities. This includes the number of media streams that a device is willing to transmit and willing to receive for a given media channel of a particular type (audio or video). It also allows the receiver to specify which media positions it is willing to transmit and receive. The reception of an RTCP APP MUXCTRL packet or an RTCP APP MUXCTRL ACK packet specifying the TIP private application name, “xcts”, is used as acknowledgement that TIP is understood by the remote peer. TIP requires that the local system’s MUXCTRL be acknowledged by the remote peer and that the MUXCTRL of the remote peer be received before communication under the rules of TIP can begin. The RTCP APP packets and processing rules are detailed described in section 4.2 4.2. The TIP negotiation begins MUST begin by sending the RTCP APP MUXCTRL on the RTCP UDP channel(s) indicated by the media channel establishment. For a short interval (recommendation is 15 seconds), the MUXCTRL packet should be periodically retransmitted, until an acknowledgement is received or the interval elapses without a response. The reception of either a MUXCTRL or MUXCTRL ACK packet on the RTCP UDP channel SHOULD be interpreted as support of TIP. An implementation SHOULD acknowledge all MUXCTRL packets it receives. The lack of any response MUST be interpreted as a lack of support for TIP, and hence the standard RTCP traffic should be sent on the RTCP UDP channel as per the standard mode of operation for [4], unless the peer has signaled otherwise in SDP [9]. If media security has been negotiated, the RTCP packets described in this section would instead be SRTCP packets. For a message flow of a basic TIP control channel setup, refer to section 7.1.