Patent Publication Number: US-2011055893-A1

Title: Communication application

Description:
BACKGROUND 
     One of the challenges for remote communications (e.g., videoconferencing) is session initiation. In order to initiate a session, a discovery process and then a connection process are generally needed. For example, a local user may initiate a communication session by discovering and connecting to a remote user. To facilitate the discovery and connection processes, various proprietary communication services enable users to set up an account. Such accounts typically enable each user to manage a contact list and to initiate a communication session with online users in their contact list. As the number of communication services that are available increase, the effort that will be needed by each user to manage different accounts with different contact lists also increases. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       For a detailed description of exemplary embodiments of the invention, reference will now be made to the accompanying drawings in which: 
         FIG. 1  illustrates a system in accordance with embodiments of the disclosure; 
         FIG. 2  illustrates various software components of a communication application in accordance with an embodiment of the disclosure; 
         FIG. 3  illustrates various operations of a communication application in accordance with an embodiment of the disclosure; 
         FIG. 4  illustrates use of identifiers for a communication application in accordance with an embodiment of the disclosure; 
         FIG. 5  illustrates a communication technique between two endpoints in accordance with an embodiment of the disclosure; and 
         FIG. 6  illustrates a method in accordance with embodiments of the disclosure. 
     
    
    
     NOTATION AND NOMENCLATURE 
     Certain terms are used throughout the following description and claims to refer to particular system components. As one skilled in the art will appreciate, computer companies may refer to a component by different names. This document does not intend to distinguish between components that differ in name but not function. In the following discussion and in the claims, the terms “including” and “comprising” are used in an open-ended fashion, and thus should be interpreted to mean “including, but not limited to . . . .” Also, the term “couple” or “couples” is intended to mean either an indirect, direct, optical or wireless electrical connection. Thus, if a first device couples to a second device, that connection may be through a direct electrical connection, through an indirect electrical connection via other devices and connections, through an optical electrical connection, or through a wireless electrical connection. 
     DETAILED DESCRIPTION 
     The following discussion is directed to various embodiments of the invention. Although one or more of these embodiments may be preferred, the embodiments disclosed should not be interpreted, or otherwise used, as limiting the scope of the disclosure, including the claims. In addition, one skilled in the art will understand that the following description has broad application, and the discussion of any embodiment is meant only to be exemplary of that embodiment, and not intended to intimate that the scope of the disclosure, including the claims, is limited to that embodiment. 
       FIG. 1  illustrates a system  100  in accordance with embodiments of the disclosure. As shown in  FIG. 1 , the system  100  comprises a computer system  102  coupled to a communication endpoint  140  via a network  120 . The computer system  102  is representative of a desktop computer, a laptop computer, a “netbook”, a smart phone, a personal digital assistant (PDA), or other electronic devices. Although only one communication endpoint  140  is shown, it should be understood that the computer system  102  may be coupled to a plurality of communication endpoints via the network  120 . Further, it should be understood, that the computer system  102  is itself a communication endpoint. As used herein, a “communication endpoint” refers to an electronic device that is capable of running a communication application and supporting a peer-to-peer communication session. 
     In accordance with embodiments, the computer system  102  and communication endpoints (e.g., the communication endpoint  140 ) employ respective communication applications  110  and  142  to facilitate an efficient communication session. As shown, the communication application  110  comprises first stage instructions  112  and second stage instructions  114 . Likewise, the communication application  142  comprises first stage instructions  144  and second stage instructions  146 . Various operations related to the first and second stage instructions will later be described. 
     As shown in  FIG. 1 , the computer system  102  comprises a processor  104  coupled to a system memory  106  that stores the communication application  110 . In accordance with embodiments, the processor  104  may correspond to at least one of a variety of semiconductor devices such as microprocessors, central processing units (CPUs), microcontrollers, main processing units (MPUs), digital signal processors (DSPs), advanced reduced instruction set computing (RISC) machines, ARM processors, application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs) or other processing devices. In operation, the processor  104  performs a set of predetermined functions based on data/instructions stored in or accessible to the processor  104 . In at least some embodiments, the processor  104  accesses the system memory  106  to obtain data/instructions for the predetermined operations. The system memory  106  is sometimes referred to as a computer-readable storage medium and may comprise volatile memory (e.g., Random Access Memory), non-volatile memory (e.g., a hard drive, a flash drive, an optical disk storage, etc.), or both. 
     To support a communication session, the computer system  102  comprises communication devices  118  coupled to the processor  104 . The communication devices may be built-in devices and/or peripheral devices of the computer system  102 . As an example, the communication devices  118  may correspond to various input devices and/or output devices such as a microphone, a video camera (e.g., a web-cam), speakers, a video monitor (e.g., a liquid crystal display), a keyboard, a keypad, a mouse, or other devices that provide a user interface for communications. Each communication endpoint (e.g., the communication endpoint  140 ) also may include such communication devices. 
     To enable remote communications with the network  120 , the computer system  102  comprises a network interface  116  coupled to the processor  104 . The network interface  116  may take the form of modems, modem banks, Ethernet cards, Universal Serial Bus (USB) interface cards, serial interfaces, token ring cards, fiber distributed data interface (FDDI) cards, wireless local area network (WLAN) cards, radio transceiver cards such as code division multiple access (CDMA) and/or global system for mobile communications (GSM) radio transceiver cards, or other network interfaces. In conjunction with execution of the communication application  110  by the processor  104 , the network interface  116  enables establishment and maintenance of a communication session between the computer system  102  and the communication endpoint  140 . 
     In accordance with at least some embodiments, execution of the first stage instructions  112  causes a selective exchange of primary connection information between the computer system  102  and the communication endpoint  140 . As used herein, “primary connection information” refers to the minimalist set of information that is needed to establish a peer-to-peer communication session between the computer system  102  and the communication endpoint  140 . In some embodiments, the primary connection information comprises user identifiers associated with the communication applications  110  and  140  and internet protocol (IP) addresses of the computer system  102  and the communication endpoint  140 . In other words, the computer system  102  receives the user identifier of a user logged into the communication application  142  and receives the IP address of the communication endpoint  140 . On the other hand, the communication endpoint  140  receives the user identifier of a user logged into the communication application  110  and receives the IP address of the computer system  102 . 
     In at least some embodiments, successful exchange of the primary connection information is dependent on prior user authentications performed at each of the computer system  102  and the communication endpoint  140 . Such user authentication may be based on verification of username/password, biometrics, smartcard information and/or other identifiers. For example, successful user authentication at the computer system  102  results in a user having access to various features of the communication application  110  (i.e., the user is logged into the communication application  110 ) including a user interface that presents information to the user (e.g., via a display monitor). 
     With access to the user interface of the communication application  110 , the user at the computer system  102  is able to request initiation of a peer-to-peer communication session with one or more users currently “online” at their respective communication endpoints. To detect a user&#39;s online status, the computer system  102  accesses information maintained by at least one of a plurality of gateway servers  130 A- 130 N coupled to the network  120 . As shown in the embodiment of  FIG. 1 , each of the gateway servers  130 A- 130 N maintains a respective contact list  132 A- 132 N and respective presence information  134 A- 134 N related to users corresponding to each contact list  132 A- 132 N. The presence information  134 A- 134 N indicates whether a user is “online” and is accumulated by the gateway servers  130 A- 130 N as users log into a service application provided by the gateway servers  130 A- 130 A. In other words, the communication application  110  is able to indirectly populate its own contact list and presence information based on predetermined contact lists (e.g., the contact lists  132 A- 132 N) and corresponding presence information (e.g., the presence information  134 A- 134 N) maintained by gateway servers  130 A- 130 N. Examples of the gateway servers  130 A- 130 N include, but are not limited to, email servers, instant messaging servers, videoconference servers, or other communication service servers that maintain a contact list and presence information. Gmail®, Jabber®, and Office Communicator® are examples of communication services with corresponding servers that maintain contact lists and presence information. In some embodiments, the computer system  102  itself maintains a local contact list and presence information that is accessible by the communication application  110  for populating the contact list and presence information of the communication application  110 . 
     In order to access a contact list and presence information maintained by a given gateway server, a user at the computer system  102  often logs into the communication service provided by the given gateway server. Although the user could log into each gateway server communication service separately, some embodiments of the communication application  110  enable management of the login process for all gateway service accounts associated with the user of the computer system  102 . For example, when a user successfully logs into the communication application  110 , all gateway server accounts associated with the user are automatically activated (e.g., by completing a login process for each gateway server account). Alternatively, a user at the computer system  102  may select a default sub-set of gateway server accounts to be activated upon a successful login process for the communication application  110 . In either case, the communication application  110  facilitates the selection of individuals to participate in a communication session by populating a contact list (sometimes referred to as a “buddy list”) from predetermined contact lists (e.g., contact lists  132 A- 132 N) maintained by at least one of the gateway servers  130 A- 130 N. The communication application  110  also maintains presence information for the populated contact list based on predetermined presence information (e.g., presence information  134 A- 134 N) maintained by at least one of the gateway servers  130 A- 130 N. The communication application  110  also may maintain primary connection information for each contact in the populated contact list. 
     In accordance with at least some embodiments, another feature of the communication application  110  is the ability to update the contact lists  132 A- 132 N maintained by the gateway servers  130 A- 130 N. In other words, the communication application  110  is able to receive local updates to the populated contact list (e.g., based on user input) of the communication application  110  and is able to sync those updates with the contact lists  132 A- 132 N maintained by the gateway servers  130 A- 130 N. Each sync update may be universal in scope (affecting all gateway server accounts related to the communication application  110 ), individualized (affecting one of a plurality of gateway server accounts related to the communication application  110 ), or customized (affecting a sub-set of a plurality of gateway server accounts related to the communication application  110 ). To accomplish the sync function, contact list update commands compatible with each gateway server account are maintained by the communication application  110 . As needed, such commands are executed by the communication application  110 . It should be understood that sync updates are possible once access to each gateway server account has been obtained (e.g., based on a successful login process or other user authentication technique) and that the sync updates rely on pre-existing contact list update commands available for each gateway server account. 
     To initiate a communication session, a user at the computer system  102  selects an online user from the populated contact list of the communication application  110 . The communication session is initiated based on primary connection information that is selectively exchanged between the computer system  102  and communication endpoints (e.g., the communication endpoint  140 ). In some embodiments, the primary connection information is embedded into communication packets (e.g., presence information packets) corresponding to a gateway server communication service provided by at least one of the gateway servers  130 A- 1   30 N. In other words, once a user has logged into the communication application  110  and subsequently logged into gateway server accounts related to the communication application  110 , the exchange of primary connection information between the computer system  102  and communication endpoints is facilitated by embedding the primary connection information into communication packets (e.g., presence information packets) exchanged as part of a gateway server communication service protocol. In some cases, there may be more than gateway server communication service available to exchange primary connection information since the user of the computer system  102  and the selected online user may be logged into multiple gateway server accounts at the same time. Regardless of the number of available gateway server communication services that are used, the communication application  110  may collect and, as needed, update primary connection information for all contacts in a buddy list associated with the communication application  110 . The communication application  110  also may broadcast the primary connection information of the user logged into the communication application  110  to other communication endpoints in the same manner (i.e., via an available gateway server communication service). 
     As needed, the primary connection information is utilized to establish a peer-to-peer communication session between the computer system  102  and the communication endpoint of the selected online user. Although the selected online user may be at any of a plurality of communication endpoints coupled to the network  120 , the discussion herein assumes the selected online user is at the communication endpoint  140 . In accordance with embodiments, the communication endpoint  140  is compatible with the communication application  110  due to its execution of the communication application  142 . By executing the communication application  142 , the primary connection information transmitted by the computer system  102  is detected and extracted from at least one communication packet related to the gateway server communication service being used. Although not required, it should be understood that each gateway server communication service may implement its own protocol. Regardless of the particular protocol associated with a gateway server communication service, the primary connection information may be embedded into at least one communication packet by filling unused spaces within the communication packets of the gateway server communication service being used. Such unused spaces are common and can be determined by reference to the protocol/specification corresponding to each gateway server communication service. 
     As an example, for Extensible Messaging and Presence Protocol (XMPP) or Jabber communication services, the primary connection information may be transmitted to a communication endpoint by populating an option status field with an XML string that contains the primary connection information. Alternatively, an optional &lt;empty&gt; field in the XMPP presence protocol or possibly the Publish/Subscribe XMPP protocol may be used to transmit the primary connection information. For Office Communicator Server (OCS) communication services, the primary connection information may be transmitted to a communication endpoint by populating a user definable field (e.g., Endpoint Location) with an XML string that contains the primary connection information. 
     Upon reception of communication packets having the primary connection information, the communication application  142  of the communication endpoint  140  causes extraction of the primary connection information. The extraction operation is supported by execution of the first stage instructions  144  of the communication application  142 . With the primary connection information, the communication applications  110  and  142  enable the users of the computer system  102  and the communication endpoint  140  to selectively participate in begin a communication session. For example, each user may accept or reject an invitation by the other to participate in a communication session. 
     In some embodiments, if a selected online user rejects an invitation to participate in a communication session, the first stage instructions  144  either cause the communication endpoint  140  to transmit a negative response back to the computer system  102  (e.g., using the same gateway server communication service that was used to make the initial request), to ignore the invitation, or to otherwise reject the invitation. In such case, the computer system  102  is unable to start a peer-to-peer communication session with the communication endpoint  140 . 
     If the selected online user accepts an invitation to participate in a communication session, a peer-to-peer communication session between the computer system  102  and the communication endpoint  140  is established based on the primary connection information. In accordance with at least some embodiments, successful establishment of the peer-to-peer communication session causes the communication applications  110  and  142  to transition from execution of the first stage instructions  112  and  144  to execution of the second stage instructions  114  and  146 . 
     In at least some embodiments, the second stage instructions  114  and  146  cause supplemental connection information used during the peer-to-peer communication session to be exchanged between the computer system  102  and the communication endpoint  140 . This exchange of supplemental connection information occurs after the peer-to-peer communication session between the computer system  102  and the communication endpoint  140  has been initiated. As used herein, “supplemental connection information” refers to information and/or parameters that facilitate a communication technique, but that are not necessary for initiation of a communication session. As an example, in an embodiment where the communication session corresponds to a teleconference, the supplemental connection information comprises audio/video codecs. Additionally or alternatively, the supplemental information may comprise, for example, screen resolution, encryption methodology, and/or network port negotiation. In alternative embodiments, the communication session may correspond to a peer-to-peer desktop sharing session. In such case, supplemental information may comprise, for example, screen resolution, encryption methodology, and/or network port negotiation. 
       FIG. 2  illustrates various software components of a communication application  200  in accordance with an embodiment of the disclosure. The communication application  200  may correspond, for example, to either of the communication applications  110  and  142  of  FIG. 1 . As shown, the communication application  200  comprises a management module  202  that supports various management functions of the communication application  200 . The management module  202  may be programmed using WexDomain. As shown, the management module  202  supports a “Buddy Manager”, a “Property Manager”, a “Log Manager”, a “Credentials Manager”, a “Gateway Manager”, a “Conference Manager”, an “AudioNideo (AN) Manager”, and a “Remote Command Manager.” 
     The Buddy Manager of the management module  202  maintains a contact list for the communication application  200 . The Property Manager of the management module  202  enables administrative modification of various internal properties of the communication application  200  such as communication bandwidth or other properties. The Gateway Manager of the management module  202  provides an interface for the communication application  200  to communicate with gateway servers  254 A- 254 C. As shown, there may be individual interfaces  232 A- 232 C corresponding to different gateway servers  254 A- 254 C since each gateway server may implement a different protocol. Examples of the interfaces  232 A- 232 C include, but are not limited to, an XMPP interface, an OCS interface, and a local interface. 
     Meanwhile, the Conference Manager of the management module  202  handles communication session features such as session initiation, time-outs, or other features. The Log Manager of the management module  202  is a debug feature for the communication application. The Credentials Manager of the management module  202  handles login information (e.g., username, password) related to the gateway servers  254 A- 254 C so that an automated login process to the gateway servers  254 A- 254 C is provided by the communication application  200 . The A/V Manager of the management module  202  sets up an ANV pipeline to support the communication session. The Remote Commands Manager of the management module  202  provides remoting commands that enable the communication endpoint (e.g., the computer system  102 ) that implements the communication application  200  to send information to and receive information from a remote computer. 
     As shown, the management module  202  interacts with various other software modules. In at least some embodiments, the management module  202  sends information to and receives information from a user interface (UI) module  204 . The UI module  204  may be based on, for example, Windows Presentation Foundation (WPF) or “Qt” software. In the embodiment of  FIG. 2 , the management module  202  sends information to the UI module  204  using a “boost” event invoker  208 . As used herein, “boost” refers to a set of C++ libraries that can be used in code. On the other hand, the UI module  204  sends information to the management module  202  using a C++ interop or Command Language Intrastructure (CLI) interop. The management module  202  also interacts with a &lt;&lt;remote&gt;&gt; domain module  224  that uses remote commands of the Remote Command Manager of the management module  202  to initiate and carry out a communication session with a remote computer. To carry out the communication session, the management module  202  interacts with an A/V pipeline module  226 . In at least some embodiments, the A/V pipeline module  226  is based on Nizza/Pericles software. In operation, the A/V pipeline module  226  discovers, configures (e.g., codec parameters), and sends information to or receives information from communication hardware  236 . Examples of communication hardware  236 , include but are not limited to, web-cams  238 A, speakers  238 B and microphones  238 C. The communication application  200  also comprises a &lt;&lt;remote&gt;&gt; A/V module  228  that interacts with the A/V pipeline  226  to extend some or all of the functions of the A/V pipeline  226  to a remote computer. As shown, all of the remoting commands (e.g., commands to the &lt;&lt;remote&gt;&gt; domain module  224 , commands to the &lt;&lt;remote&gt;&gt; domain addon module  222 , commands to the &lt;&lt;remote&gt;&gt; AN module  228 ) may be based on Internet Communications Engine (ICE) commands  230 A- 230 C. 
     In the embodiment of  FIG. 2 , the UI module  204  and the management module  202  selectively interact with a UI addon module  214 , a domain addon module  220  and a &lt;&lt;remote&gt;&gt; domain addon module  222 . In accordance with at least some embodiments, the “addon” modules ( 214 ,  220  and  222 ) extend the features of the communication application  200  for remote use without changing the core code. As an example, the addon modules  214 ,  220  and  222  may correspond to a “desktop sharing” feature that provides the functionality of the communication application  200  at a remote computer. More specifically, the UI addon module  214  provides some or all of the functions of the UI module  204  for use by a remote computer. Meanwhile, the domain addon module  220  provides some or all of the functions of the management module  202  for use by a remote computer. Meanwhile, the &lt;&lt;remote&gt;&gt; domain addon module  222  provides some or all of the functions of the &lt;&lt;remote&gt;&gt; domain module  224  for use by a remote computer. As shown, just as the management module  202  and the UI module  204  interact using interops  206  and boost event invokers  208 , the domain addon module  220  and the UI addon module  214  may interact using interops  216  and boost event invokers  218 . 
       FIG. 3  illustrates various operations of a communication application  300  in accordance with embodiments of the disclosure. The communication application  300  may correspond, for example, to either of the communication applications  110  and  142  of  FIG. 1 . Also, the communication application  300  may correspond to the communication application  200  of  FIG. 2 . In  FIG. 3 , the communication application  300  comprises various software components that interact with each other. 
     As shown, the communication application  300  comprises a user interface component (“UI”)  304  in communication with a buddy manager component  306 . The UI component  304  supports a login operation (step  1 . 0 ) to enable a user to access the buddy manager component  306 . Once the buddy manager component  308  has been accessed, various other components are accessible including a gateway manager component  308 , a conference manager component  316 , and a remote command facade component  314 . In at least some embodiments, the buddy manager component  306  issues an “open gateway” command (step  1 . 1 ) to the gateway manager component  308 . In response, the gateway manager component  308  performs a “get gateway” command (step  1 . 1 . 1 ) related to a particular gateway. If the particular gateway is not yet set up for use with the communication application  302 , the “get gateway” command causes the gateway manager component  308  to issue a “create gateway” command (step  1 . 1 . 2 ) to a gateway factory component  310 . The gateway factory component  310  manages the information and processes needed to establish a new gateway for the communication application  302 . If a gateway has already been set up for the communication application  302 , the “get gateway” command causes the gateway manager component  308  to issue a “connect” command (step  1 . 1 . 3 ) to a gateway component  312  for connecting the communication application  302  to a gateway server  320  (e.g., an Xmpp server). 
     In at least some embodiments, connection to a gateway server account provided by the gateway server  320  requires user authentication. In such cases, the buddy manager component  306  issues an “authenticate user” command (step  1 . 2 ) to the gateway manager component  308 . The gateway manager component  308  then performs several commands including an “add gateway” command (step  1 . 2 . 1 ), an “is gateway available” command (step  1 . 2 . 2 ) and a “get gateway” command ( 1 . 2 . 3 ). If the gateway server  320  is available as determined by steps  1 . 2 . 2  and  1 . 2 . 3 , the gateway manager component  308  issues an “is connected” notification (step  1 . 2 . 4 ) and an “authenticate user” command (step  1 . 2 . 5 ) to the gateway component  312 . The gateway component  312  issues a “connect” command (step  1 . 2 . 6 ) to connect to the gateway server  320 . In response to the connect command, the gateway server  320  provides a roster (step  1 . 2 . 7 ) to the gateway component  312 . Based on the roster, the gateway component  312  performs a “build buddy list” command (step  1 . 2 . 8 ) and populates a particular buddy list corresponding to the user logged into the communication application  300 . 
     As needed, the buddy manager component  306  issues a “get buddy details” command (step  1 . 3 ) to the gateway manager component  308 . In response, the gateway manager component  308  performs several commands including an “is gateway available” command (step  1 . 3 . 1 ) and a “get gateway” command (step  1 . 3 . 2 ). If the gateway server  320  is available as determined by steps  1 . 3 . 1  and  1 . 3 . 2 , the gateway manager component  308  issues a “get buddy details” command (step  1 . 3 . 3 ) to the gateway component  312 . In response, the gateway component  312  provides buddy details based on the populated buddy list maintained by the gateway component  312 . Examples of buddy details include, but are not limited to, a name, an email address, a picture (avatar), or other personal information. 
     In at least some embodiments, a user is able to update the populated buddy list maintained at the gateway component  312 . To update the populated buddy list, the buddy manager component  306  issues a “set buddy details” commands (step  1 . 4 ) to the gateway manager component  308 . In response, the gateway manager component  308  performs several commands including an “is gateway available” command (step  1 . 4 . 1 ) and a “get gateway” command (step  1 . 4 . 2 ). If the gateway server  320  is available as determined by steps  1 . 4 . 1  and  1 . 4 . 2 , the gateway manager component  308  issues the “set buddy details” command (step  1 . 4 . 3 ) to the gateway component  312 . In response, the gateway component  312  sets buddy details in the populated buddy list maintained by the gateway component  312 . As previously mentioned, examples of buddy details include, but are not limited to, a name, an email address, a picture (avatar), or other personal information. In accordance with at least some embodiments, the “get buddy details” command and the “set buddy details” command enables a user of the communication application  300  to view and update his/her own personal information. Additionally, the “get buddy details” command may be used to view the personal information of someone in the populated contact list. In some embodiments, the populated contact list only displays abbreviated information (e.g., a username) unless additional information is requested using the “get buddy details” command or the “set buddy details” command. 
     The buddy manager component  306  may also issue a “get buddy list” command (step  1 . 5 ) to the gateway manager component  308 . In response, the gateway manager component  308  performs several commands including an “is gateway available” command (step  1 . 5 . 1 ) and a “get gateway” command (step  1 . 5 . 2 ). If the gateway server  320  is available as determined by steps  1 . 5 . 1  and  1 . 5 . 2 , the gateway manager component  308  issues the “get buddy list” command (step  1 . 5 . 3 ) to the gateway component  312 . In response, the gateway component  312  obtains the buddy list associated with the authenticated user from the gateway server  320 . If there are multiple gateway servers, the “get buddy list” command may result in a consolidated and sorted buddy list obtained from multiple gateway servers. 
     At step  1 . 6 , the buddy manager component  306  issues a “set buddy” command to the remote command facade component  314 . At step  1 . 7 , the buddy manager component  306  performs a “send my status” command to notify the gateway server  320  regarding the online status of the user logged into the communication application  300 . The communication application  300  also needs to track the online status of the contacts in the populated buddy list. To accomplish this, the buddy manager component  306  issues a “set buddy status” command (step  1 . 8 ) to the gateway manager component  308 . In response, the gateway manager component  308  performs several commands including an “is gateway available” command (step  1 . 8 . 1 ) and a “get gateway” command (step  1 . 8 . 2 ). If the gateway server  320  is available as determined by steps  1 . 8 . 1  and  1 . 8 . 2 , the gateway manager component  308  issues the “set buddy status command (step  1 . 8 . 3 ) to the gateway component  312 . In response, the gateway component  312  performs a “build Overture presence string” command (step  1 . 8 . 4 ) to broadcast and receive primary connection information (e.g., an XML string) in communication packets of a gateway server communication service associated with the gateway server  320 . As used herein, “Overture” refers to the name of the communication application  300 . The exchange of primary connection information is performed by the gateway component  312  issuing various commands to the gateway server  320 . Specifically, the gateway component  312  may issue a “change presence” command (step  1 . 8 . 5 ) and a “set status” command (step  1 . 8 . 6 ) to broadcast primary connection information to online users via the gateway server  320 . Further, the gateway component  312  may issue a “probe presence” command (step  1 . 8 . 7 ) to gateway server  320  collect primary connection information for each contact in the populated buddy list. 
     At step  1 . 9 , the buddy manager component  306  issues a login command to the conference manager component  316 . The buddy manager component  306  then performs a “notify observers of login” command (step  1 . 10 ). Steps  1 . 9  and  1 . 10  enable a user to invite at least one online user in the populated buddy list to participate in a communication session. 
     Periodically, the gateway server  320  provides “Overture presence” information to the gateway component  312  (step  2 . 0 ). In response, the gateway component  312  performs a “parse and store Overture information” command (step  2 . 0 . 1 ). With the overture information from the gateway server  320  parsed and stored, the gateway component  312  is able to issue a “buddy status changed” command (step  2 . 0 . 2 ) and a “buddy details changed” command (step  2 . 0 . 3 ) to the buddy manager component  306 . As needed, the gateway component  312  may issue a “change presence” command (step  2 . 0 . 4 ) to the gateway server  320  to notify the gateway server  320  if the user of the communication application  300  logs out or otherwise changes his/her online status. Step  2 . 0  (including steps  2 . 0 . 1 - 2 . 0 . 4 ) enables users to periodically update presence information as well as primary connection information for use by the communication application  300 . 
       FIG. 4  illustrates use of identifiers for a communication application in accordance with an embodiment of the disclosure. In the embodiment of  FIG. 4 , blocks  406  and  408  correspond to primary connection information as described herein. The information in blocks  406  and  408  are obtained from gateway servers  402  and  404 . As an example, the gateway server  402  corresponds to a XMPP server and the gateway server  404  corresponds to an OCS server. The primary connect information may be provided by either of the gateway servers  402  and  404 . In other words, the primary connection information in blocks  406  and  408  is based on communication packets  414 A and  414 C obtained from the gateway server  402 . Alternatively, the primary connection information in blocks  406  and  408  is based on communication packets  414 B and  414 B obtained from the gateway server  404 . 
     The primary connection information is used to formulate a “start conference request”  440  that is based on the IP addresses of the endpoints involved and the usernames of users logged into the respective communication applications. In accordance with embodiments, issuance of the start conference request  440  is based on a gateway server communication service provided by one of the gateway servers  402  and  404 . As an example,  FIG. 4  shows issuance of the start conference request  440  based on an XMPP service provided by the gateway server  402 .  FIG. 4  also shows that some information for the start conference request  440  may be obtained from local servers  410  and  412 . In accordance with at least some embodiments, each communication endpoint that participates in a communication session is able to compile information to facilitate the start conference request  440 . For example, in  FIG. 4 , a select username related to a communication application (referred to as “Overture” herein) and a select gateway server communication service for use with the start conference request  440  are obtained from compiled lists  430  and  432 . 
     In summary, each of the communication applications described herein (e.g., communication applications  110 ,  142 ,  200 ,  302 ) may correspond to an application that is stored on a computer-readable medium. When executed by a processor, a communication application causes a processor to selectively exchange primary connection information of a computer system and a communication endpoint via a network interface. In at least some embodiments, the exchange of primary connection information is limited to user identifiers associated with the communication application and internet protocol (IP) addresses. In at least some embodiments, a communication application further causes a processor to initiate a peer-to-peer communication session with the communication endpoint based on the primary connection information. A communication application, when executed, may further cause the processor to perform a user authentication process at the computer system and, if the user authentication process results in successful user authentication, to exchange the primary connection information. A communication application, when executed, may further cause the processor to populate a contact list and to maintain contact availability information based on predetermined contact list information and predetermined contact availability information maintained by at least one gateway server coupled to the network interface. A communication application, when executed, may further cause the processor to exchange audio codes or video codes between the computer system and the communication endpoint after the peer-to-peer communication session has been initiated. A communication application, when executed, may further cause the processor to maintain a single contact list based on a plurality of contact lists accessible via at least one gateway server coupled to the network interface. 
       FIG. 5  illustrates a communication technique  500  between two endpoints in accordance with an embodiment of the disclosure. In  FIG. 5 , the steps begin chronologically at the top (nearest the blocks representing endpoints  502 ,  504  and instant messaging (IM) server  506 ) and proceed downward. As shown, the IM server  506  authenticates a user of the endpoint A  502 . In response, the endpoint A  502  receives a contact list from the IM server  506 . Next, the IM server  506  authenticates a user of the endpoint B  504 . In response, the endpoint B  504  receives a contact list from the IM server  506 . Based on the contact list from the IM server  506 , endpoint A  502  sends connection information to the IM server  506 , which forwards endpoint A connection information to the endpoint B  504 . Similarly, endpoint B  504  sends connection information to the IM server  506 , which forwards endpoint B connection information to the endpoint A  502 . In other words, the endpoint A  502  and the endpoint B  504  exchange primary connection information via the IM server  506 . Subsequently, the endpoint A  502  is able to initiate a conference with endpoint B  504 . Upon a successful response from the endpoint B  504  (i.e., a user of endpoint B  504  accepts a request to participate in a communication session with a user of endpoint A  502 ), a media exchange occurs. The media exchange may be audio, video, still images, text and/or media. Eventually, the conference terminates. 
       FIG. 6  illustrates a method  600  in accordance with embodiments of the disclosure. In accordance with embodiments, the method  600  is a computer-implemented method. As shown, the method  600  comprises selectively exchanging primary connection information of a computer system and a communication endpoint via a network interface (block  602 ). In at least some embodiments, the primary connection information is limited to user identifiers associated with a communication application and internet protocol (IP) addresses. The method  600  also comprises initiating a peer-to-peer communication session between the computer system and the communication endpoint based on the primary connection information (block  604 ). 
     The method  600  may comprise additional steps that are added individually or in combination. As an example, the method  600  may additionally comprise performing a user authentication process at the computer system and, if the user authentication process results in successful user authentication, then exchanging said primary connection information. The method  600  may additionally comprise maintaining a single contact list based on a plurality of contact lists accessible via at least one gateway server coupled to the network interface. The method  600  may additionally comprise exchanging supplemental connection information between the computer system and the communication endpoint after the communication session has been initiated based on the primary connection information. The supplemental information may be audio/video codecs or other information that facilitates communication, but is not required to establish a peer-to-peer communication session. 
     The above discussion is meant to be illustrative of the principles and various embodiments of the present invention. Numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to embrace all such variations and modifications.