Patent Document

CROSS-REFERENCE TO RELATED APPLICATIONS 
     This application is a continuation of U.S. patent application Ser. No. 10/245,476, entitled “Proximity Detection for Media Proxies”, filed Sep. 17, 2002, which is hereby incorporated by reference in its entirety as though fully and completely set forth herein. 
    
    
     FIELD OF THE INVENTION 
     The present invention relates to a technique to determine a best path over which a multimedia communication session may be held. 
     BACKGROUND OF THE INVENTION 
     Consumers of telecommunications services are faced with many options when it comes to services. One of the more dynamic fields currently is the provision of multimedia services. Typically, a consumer will request multimedia services by accessing an application server. The application server will direct the consumer to one of a plurality of media proxies in a round robin fashion. The media proxy may then set up and tear down the call as is well understood and provide other multimedia related services. 
     The round robin approach suffers from some drawbacks. First, the round robin approach ignores the loads that are currently being experienced on the media proxies; for instance, there is no provision to evaluate loading on the media proxies before making the assignment. As such, a heavily loaded media proxy may still be assigned to provide services to a consumer just because it is next in the round robin cycle. 
     Second, the round robin approach ignores distances between the media proxy and the consumer. The distance may be a function of communication links, physical distance, and similar physical attributes. Distance introduces delay into the provision of services, which for multimedia applications can be extremely undesirable. The round robin approach assigns a media proxy to a consumer irrespective of whether another media proxy might be closer. 
     Thus, there is a need for a better technique to allocate media proxies to incoming requests. 
     SUMMARY OF THE INVENTION 
     The present invention addresses the shortcomings of the round robin approach by determining which media proxy is “closest” to the client and assigning that media proxy to the client. Initially, a proximity server, which in a preferred embodiment is a database server, associated with an application determines a round trip time required for a message to go from the database server to each media proxy and back. Subsequently, the application server may receive a request for multimedia services from a client. The application server returns a list of available media proxies to the client for which the database server has the round trip times. The client then sends out a probe query to each media proxy on the list. The media proxies, upon receipt of the probe, send a time-stamped message to the database server. The database server determines which media proxy is closest to the client based on the round trip times and the time required for the media proxy to receive the probe query from the client. After the determination, the application server assigns the client to a media proxy and the media services are provided as requested. 
     Those skilled in the art will appreciate the scope of the present invention and realize additional aspects thereof after reading the following detailed description of the preferred embodiments in association with the accompanying drawing figures. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The accompanying drawing figures incorporated in and forming a part of this specification illustrate several aspects of the invention, and together with the description serve to explain the principles of the invention. 
         FIG. 1  illustrates a network according to one embodiment of the present invention; 
         FIG. 2  illustrates, as a flow chart, the methodology of the present invention; and 
         FIG. 3  illustrates a call flow diagram associated with the exemplary embodiment of  FIG. 2 . 
     
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
     The embodiments set forth below represent the necessary information to enable those skilled in the art to practice the invention and illustrate the best mode of practicing the invention. Upon reading the following description in light of the accompanying drawing figures, those skilled in the art will understand the concepts of the invention and will recognize applications of these concepts not particularly addressed herein. It should be understood that these concepts and applications fall within the scope of the disclosure and the accompanying claims. 
     Before discussing how the present invention works, an explanation of the network environment is presented so as to help understand the context of the present invention. A network  10  may be the public internet (shown), a private intranet, or other network through which various elements may interact, such as through any appropriate packet based protocol. A client  12  may be communicatively coupled to the network  10 . The client  12  may be a personal computer, a multimedia enabled phone, or other multimedia enabled customer premises equipment. One or more points of presence (POPs)  14 ,  16  may be associated with one or more service providers. The POPs  14 ,  16  may have one or more media proxies (MPs)  18 A,  18 B, and  18 C (hereinafter, generically a media proxy  18 ) associated therewith, as well as a proximity server  20 , which in a preferred embodiment is a database server. In most installations, it is expected that a single application server  22  may control more than one media proxy  18 , and further the application server  22  may control media proxies  18  distributed amongst multiple POPs  14 ,  16 . The application server  22  may, in an exemplary embodiment, use Session Initiation Protocol (SIP) for communicating. 
     For the sake of providing a more complete explanation, a brief digression into the specifics of SIP is herein provided. A SIP endpoint is generally capable of running an application, which is generally referred to as a user agent (UA), and is capable of facilitating media sessions using SIP. User agents register their ability to establish sessions with a SIP proxy (the application server  22  in the present invention) by sending “REGISTER” messages to the SIP proxy. The REGISTER message informs the SIP proxy of one or more SIP universal resource locators (URL) that identify the user agent to the SIP network. The REGISTER message also contains information about how to reach specific user agents over the SIP network by providing the Internet Protocol (IP) address and port that the user agent will use for SIP sessions. 
     A “SUBSCRIBE” message may be used to subscribe to an application or service provided by a SIP endpoint. Further, “NOTIFY” messages may be used to provide information between SIP endpoints in response to various actions or messages, including REGISTER and SUBSCRIBE messages. 
     When a user agent wants to establish a session with another user agent, the user agent initiating the session will send an INVITE message to the SIP proxy and specify the targeted user agent in the “TO:” header of the INVITE message. Identification of the user agent takes the form of a SIP URL. In its simplest form, the URL is represented by a number or “&lt;username&gt;@&lt;domain&gt;,” such as “janedoe@nortelnetworks.com.” Generally, the user name is unique within the name space of the specified domain. 
     If the targeted user agent has registered with the SIP proxy, the SIP proxy will forward any received INVITE message directly to the targeted user agent. The targeted user agent will respond with a 200 OK message, and a session between the respective user agents will be established as per the message exchange required in the SIP specification. Media capabilities are passed between the two user agents of the respective endpoints as parameters embedded within the session setup messages, such as the INVITE, 200 OK, and acknowledgement (ACK) messages. The media capabilities are typically described using the Session Description Protocol (SDP). Once respective endpoints are in an active session with each other and have determined each other&#39;s capabilities, the specified media content may be exchanged during an appropriate media session. 
     Returning now to the present invention, the proximity server  20  has a pre-configured list of media proxies  18 , and more specifically, a list of addresses and ports on the media proxies  18  that serve the domains served by the application server  22 . Further, at least one port on each media proxy  18  is reserved for running the proximity detection method of the present invention. 
     Note that, in general, the client  12 , the media proxy  18 , the proximity server  20 , and the application server  22  all may contain data processing devices, such as a microprocessor. Further, the microprocessor may be controlled by software or hardware that performs the functions of the present invention. The software may be stored on any appropriate computer readable medium such as a hard drive, a disc, or other memory device. Note further that it is possible that the proximity server  20  and the application server  22  be collocated or integrated into a single entity, but such is not required. The proximity server is one possible host for the proximity detection algorithm. The algorithm is independent of any platform. 
     The methodology of the present invention will now be presented with reference to  FIGS. 2 and 3 .  FIG. 2  is a flowchart of the methodology and  FIG. 3  shows the call flows. Steps in the flow chart begin with the numeral one, such as block  100 , while steps in the call flow begin with the numeral two, such as message  200 . While particular protocols and messaging examples are provided, they are intended to be exemplary and assist in comprehension of the steps of the present invention. Other messaging protocols could be used as needed or desired. 
     In an exemplary embodiment, the proximity server  20  periodically estimates a round trip time (RTT) between the proximity server  20  and each of the media proxies  18  under its jurisdiction (block  100 ). This RTT estimation may be done using an Internet Control Message Protocol (ICMP) ping as is well understood. At some time subsequent to the estimation of the RTT, a client  12 , which may be a SIP client, sends a SIP REGISTER message ( 200 ) requesting registration with the application server  22  (block  102 ) as part of a request for multimedia services. The application server  22  sends the pre-configured list of addresses (including port addresses, if appropriate) to the client  12  for media proxies  18  that are available to serve the domain from which the client&#39;s request originates (block  104 ). This list of media proxies  18  can be sent in the body of the 200 OK response to the REGISTER message ( 202 ). 
     The client  12  sends a Simple Traversal of UDP Through Network Address Translators (STUN), ICMP ping, or an application layer probe message ( 204 A,  204 B,  204 C) to all of the media proxies  18  in the list received from the application server  22  (block  106 ). This message may include the user identification (USER ID) of the client  12 . The probe may be sent out essentially simultaneously. 
     Each media proxy  18 , upon receiving the probe message, sends a notification message ( 206 A,  206 B,  206 C) reporting the probe event to the proximity server  20  (block  108 ). This notification message may contain the user identification of the client  12  that triggered the event, as well as a timestamp (TIME). The media proxy  18  also sends back an acknowledgement ( 208 A,  208 B,  208 C) to the client  12  (block  110 ) probe. The acknowledgement informs the client  12  which media proxies  18  are reachable. Optionally, the media proxy  18  may include in the notification message ( 206 A,  206 B,  206 C) a timestamp delta representing the time between the receipt of the client probe and the time of sending the notification message to the proximity server  20 . In an exemplary embodiment, the timestamp delta value has a granularity of milliseconds, although finer gradations could be used. 
     The proximity server  20  notes the time of receipt of the notification messages (block  112 ). The proximity server  20  then uses these values and the round trip time (RTT) previously gathered for each of the media proxies  18  to estimate the relative proximities of the client  12  to each of the media proxies  18  (block  114 ). While there may be several ways to estimate the proximity, an exemplary method to estimate the proximity is as follows. 
     RTT_A, RTT_B, and RTT_C are the RTTs for the media proxies  18 A,  18 B, and  18 C, respectively. TA, TB, and TC are the recorded times at the proximity server  20  representing the receipt of the notification messages. The relative proximity values may thus be computed as:
 
Prox( A,B )=( TA−TB )−( RTT   —   A−RTT   —   B )  i.
 
Prox( A,C )=( TA−TC )−( RTT   —   A−RTT   —   C )  ii.
 
Prox( B,C )=( TB−TC )−( RTT   —   B−RTT   —   C )  iii.
 
     Note that if the timestamp deltas are present, they may be subtracted out of the calculation for greater accuracy. For example, if  A  and  B  are present, then Prox (A, B)=(TA−TB)−(RTT_A−RTT_B)−( A − B ). Following the rule that if Prox (A, B)&lt;0 (or negative), then media proxy  18 A is relatively closer to the client  12  than media proxy  18 B, the following table may be constructed. 
     
       
         
               
               
               
               
             
           
               
                   
               
               
                   
                   
                   
                 Relative Proximities 
               
               
                 Prox (A, B) 
                 Prox (A, C) 
                 Prox (B, C) 
                 from client 
               
               
                   
               
             
             
               
                 − 
                 − 
                 − 
                 A &lt; B &lt; C 
               
               
                 − 
                 − 
                 + 
                 A &lt; C &lt; B 
               
               
                 − 
                 + 
                 − 
                 ERROR 
               
               
                 − 
                 + 
                 + 
                 C &lt; A &lt; B 
               
               
                 + 
                 − 
                 − 
                 B &lt; A &lt; C 
               
               
                 + 
                 − 
                 + 
                 ERROR 
               
               
                 + 
                 + 
                 − 
                 B &lt; C &lt; A 
               
               
                 + 
                 + 
                 + 
                 C &lt; B &lt; A 
               
               
                   
               
             
          
         
       
     
     In the event of the two error cases, the relative proximities cannot be properly determined, and the RTTs of the media proxies  18  may be used to represent client  12  proximity. Using the RTTs is a good approximation so long as the proximity server  20  is located close to the client  12 . Note that this proximity detection may, in an exemplary embodiment, only be performed once per registration. 
     Armed with the relative proximities, the proximity server  20  may then evaluate other factors (block  116 ), which include such relatively static factors as: 1) the number of hops between the media proxy  18  and the client  12  and 2) media proxy  18  capacity. Additional dynamic parameters may include the number of User Data Protocol (UDP) ports available, the processing power available, the bandwidth available, and statistics relating to jitter, delay, and packet loss at each port. These additional factors may be normalized and weighted as needed or desired to effectuate an appropriate analysis of the suitability of assigning a client  12  to a given media proxy  18 . 
     The proximity server  20  then sends a best fit message ( 210 ) to the application server  22  (block  118 ). The best fit message ( 210 ) indicates which media proxy  18  is most appropriate for the client  12  to use and is based on the proximity and the additional factors outlined above. 
     The application server  22  then instructs with message  212  the client  12  to use the selected media proxy  18  (block  120 ). Note that the proximity server  20  could provide the instruction to the client  12 . Likewise, the processing of the proximity calculations could be performed in the application server  22 , although such is not preferred. 
     Appropriate authentication or encryption steps may be taken to prevent duplication of the user identification that may be sent in some of the various messages. Likewise, denial of service attacks may be prevented in standard ways, such as monitoring traffic levels. 
     Those skilled in the art will recognize improvements and modifications to the preferred embodiments of the present invention. All such improvements and modifications are considered within the scope of the concepts disclosed herein and the claims that follow.

Technology Category: 5