8.  Protocol Transactions

   In BFCP, there are two types of transactions: client-initiated
   transactions and server-initiated transactions.

   Client-initiated transactions consist of a request from a client to a
   floor control server and a response from the floor control server to
   the client.  The request carries a Transaction ID in its common
   header, which the floor control server copies into the response.
   Clients use Transaction ID values to match responses with previously
   issued requests.

   Server-initiated transactions have different requirements and
   behavior depending on underlying transport:

      When using reliable transport, server-initiated transactions
      consist of a single message from a floor control server to a
      client (notifications).  Since they do not trigger any response,
      their Transaction ID is set to 0.

      When using unreliable transport, server-initiated transactions
      consist of a request from a floor control server to a client and a
      response from the client to the floor control server.  The
      Transaction ID must be non-zero and unique in the context of
      outstanding transactions over unreliable transports.  The request
      carries a Transaction ID in its common header, which the client
      copies into the response.  Floor control servers use Transaction
      ID values to match responses with previously issued requests.

   When using BFCP over unreliable transport, it is also required to
   choose values that let the receiver distinguish the reception of the
   next message in a sequence of BFCP messages from a retransmission of
   a previous message.  Therefore, BFCP entities using unreliable
   transport SHOULD use monotonically increasing values for the
   Transaction ID.

   When using BFCP over unreliable transports, all requests will use
   retransmission timer T1 (see Section 8.3) until the transaction is
   completed.

8.1.  Client Behavior

   A client starting a client-initiated transaction MUST set the
   Conference ID in the common header of the message to the Conference
   ID for the conference that the client obtained previously.

   The client MUST set the Transaction ID value in the common header to
   a number that is different from 0 and that MUST NOT be reused in
   another message from the client until a response from the server is
   received for the transaction.  The client uses the Transaction ID
   value to match this message with the response from the floor control
   server.

8.2.  Server Behavior

   A floor control server sending a response within a client-initiated
   transaction MUST copy the Conference ID, the Transaction ID, and the
   User ID from the request received from the client into the response.

   Server-initiated transactions MUST contain a Transaction ID equal to
   0 when BFCP is used over reliable transports.  Over an unreliable
   transport, the Transaction ID shall have the same properties as for
   client-initiated transactions: the server MUST set the Transaction ID
   value in the common header to a number that is different from 0 and
   that MUST NOT be reused in another message from the server until the
   appropriate response from the client is received for the transaction.
   The server uses the Transaction ID value to match this message with
   the response from the floor participant or floor chair.