Once a participant has identified one or more conversation partners, it can begin the conversation. But before the parties can start exchanging data via messages, they might have some housekeeping to do, for example:

• Confirm Availability: The fact that a participant can be discovered, e.g. via Consult Directory, does not guarantee that it is ready to accept messages. A participant may therefore "ping" the provider first to check availability and readiness to accept messages.
• Confirming Roles: In some peer-based conversations, participants need to agree on the role they are going to play. For example, participants may elect a leader from amongst themselves.
• Negotiate transport: Conversation participants may have different capabilities regarding transport protocols and data encoding. Two participant may want to negotiate upfront about the most efficient format that both participants support. For example, if both participants can produce and consume Protocol Buffer messages they can save a lot of bandwidth vs. JSON encoded messages.
• Authentication: A service provider may require that potential conversation partners authenticate themselves, which can range from the simple inclusion of a client ID in the initial message to more sophisticated conversations including a certificate authority.
• Sequencing: Some protocols that need to transmit reliably over unreliable channels need to synchronize first to make sure no messages are lost later.