When you send an invitation to another Windows Messenger user, you experience all the following symptoms:

• The invitation remains in a pending state in Windows Messenger.
• The Windows Messenger user who you sent the invitation to does not appear to receive the invitation.
• You do not receive an error message that is similar to the following from Microsoft Office Live Communications Server:
  Your request to have a voice conversation cannot be delivered to username.

Note This issue only occurs when you send an invitation for one of the following actions in Windows Messenger:

• Start Talking
• Start Camera
• Start Application Sharing
• Start Whiteboard
• Ask for Remote Assistance

This issue occurs if both the following conditions are true:

• The Windows Messenger user who you sent the invitation to already has a pending invitation for one of the actions that are described in the "Symptoms" section of this article.
• The server that is used to route the session invitations is also used to connect directly to an Internet Protocol-Public Switch Telephone Network (IP-PSTN) gateway.

For example, this issue occurs in the following scenario:

1. User A sends an invitation to have a voice conversation to User B.
2. User B does not respond to the invitation from User A.
3. User C sends an invitation to have a voice conversation to User B.
4. The server that User C uses to send the invitation is also used to connect directly to an IP-PSTN gateway. Therefore, this server has the trust settings applied that are described in the Microsoft Office Live Communications Server 2003 Reference Guide.

When a real-time communications client at a particular endpoint is engaged in an audio session, a video session, or a program session such as Whiteboard, Application Sharing, or Remote Assistance, that endpoint must reject new requests to participate in another similar session. By using Live Communications Server 2003, the endpoint that is currently engaged in a session sends a 486 Busy Here Session Initiation Protocol (SIP) response to the endpoint that it received the request from. In the scenario that is described in this article, the Live Communications Server proxy server does not forward the 486 Busy Here SIP response to the endpoint that sent the invitation because the trust settings on the proxy server are used incorrectly.

A mismatch of the authentication capabilities of Live Communications Server and of an IP-PSTN gateway requires that the incoming and outgoing connections between the Live Communications Server and the IP-PSTN gateway are assigned trust settings. These trust settings must not be used for client-to-server connections. If these trust settings are used, the server may not route messages that are sent over the trusted connections. In this scenario, although the invitation has been rejected by the destination endpoint, the server does not route the response and the invitation remains in a pending state in Windows Messenger.

To resolve this issue, use one of the following methods:

• Configure a Live Communications Server computer that is dedicated to route to the IP-PSTN gateway. To do this, follow the instructions in the Microsoft Office Live Communications Server 2003 Reference Guide.
• Make sure that Windows Messenger users cannot directly contact a Live Communications Server computer that has been configured for IP-PSTN connectivity.
• Turn off IP telephony.

For additional information about how to configure an IP-PSTN gateway, see "Appendix A — Setting Up IP-PSTN Connectivity" in the Microsoft Office Live Communications Server 2003 Reference Guide. This reference guide is located in the Documentation folder on the Live Communications Server 2003 CD.