|Numéro de publication||US20060031536 A1|
|Type de publication||Demande|
|Numéro de demande||US 10/851,003|
|Date de publication||9 févr. 2006|
|Date de dépôt||21 mai 2004|
|Date de priorité||21 mai 2004|
|Autre référence de publication||CN1700680A, CN1700680B, EP1599015A1, US8024476|
|Numéro de publication||10851003, 851003, US 2006/0031536 A1, US 2006/031536 A1, US 20060031536 A1, US 20060031536A1, US 2006031536 A1, US 2006031536A1, US-A1-20060031536, US-A1-2006031536, US2006/0031536A1, US2006/031536A1, US20060031536 A1, US20060031536A1, US2006031536 A1, US2006031536A1|
|Inventeurs||Vadim Eydelman, Srikanth Shoroff|
|Cessionnaire d'origine||Microsoft Corporation|
|Exporter la citation||BiBTeX, EndNote, RefMan|
|Citations de brevets (49), Référencé par (32), Classifications (25), Événements juridiques (3)|
|Liens externes: USPTO, Cession USPTO, Espacenet|
The described technology relates generally to data communications and, more particularly, to methods and systems for efficiently routing messages when using server pools.
Applications sometimes need to establish and manage a session between computing devices. A session is a set of interactions between computing devices that occurs over a period of time. As an example, real-time communications applications such as MICROSOFT MESSENGER or Voice over Internet Protocol (“VoIP”) establish sessions between communicating devices on behalf of a user. These applications may use various mechanisms to establish sessions, such as a “Session Initiation Protocol” (“SIP”). SIP is an application-layer control protocol that devices can use to discover one another and to establish, modify, and terminate sessions between devices. SIP is an Internet proposed standard. Its specification, “RFC 3261,” is available at <http://www.ietf.org/rfc/rfc3261.txt>. A specification for extensions to SIP relating to event notifications, “RFC 3265,” is available at <http://www.ietf.org/rfc/rfc3265.txt>. Both of these specifications are incorporated herein in their entirety by reference.
Applications may use SIP with another protocol to send or receive information. As an example, an application may use SIP with Real-time Transport Protocol (“RTP”) for transporting real-time data during a session. By using SIP with other protocols, applications can create and manage a session and exchange information during the session. The protocol used with SIP to exchange information may segment the information into messages. Devices may also exchange SIP messages. This exchange of messages during a session is referred to as a “dialog.” SIP may use lower-level communications layers to transport a dialog's messages, such as Transmission Control Protocol/Internet Protocol (“TCP/IP”), which are commonly employed transport- and network-layer protocols.
A SIP network comprises entities that can participate in a dialog as a client, server, or both. SIP supports four types of entities: user agent, proxy server, redirect server, and registrar. User agents initiate and terminate sessions by exchanging messages with other SIP entities. A user agent can be a user agent client, which is generally a device that initiates SIP requests, or a user agent server, which is a device that generally receives SIP requests and responds to such requests. As examples, “IP-telephones,” personal digital assistants, and any other type of computing device may be user agents. A device can be a user agent client in one dialog and a user agent server in another, or may change roles during the dialog. A proxy server is an entity that acts as a server to clients and a client to servers. In so doing, proxy servers intercept, interpret, or forward messages between clients and servers. A redirect server accepts a SIP request and generates a response directing the client that sent the request to contact an alternate network resource. A registrar is a server that accepts registration information from SIP clients and informs a location service of the received registration information.
SIP supports two message types: requests, which are sent from a client to a server, and responses, which are sent from a server to a client, generally when responding to a request. A SIP message is comprised of three parts. The first part of a SIP message is a “start line,” which includes fields to indicate a message type and a protocol version. The second part of a SIP message comprises header fields whose values are represented as name-value pairs. The third part of a SIP message is the message's body, which is used to describe the session to be initiated or contain data that relates to the session. Message bodies may appear in requests or responses.
SIP messages are routed based on the contents of their header fields. To be valid, a SIP request should contain at least the following six header fields: To, From, CSeq, Call-ID, Max-Forwards, and Via. The To header field indicates the logical identity of the recipient of the request. The From header field indicates the logical identity of the initiator of the request. The Max-Forwards header field indicates the number of hops a request can make before arriving at its destination. As an example, if a message from device A transits device B before arriving at destination device C, the message is said to have made two hops (e.g., devices B and C). The Via header field indicates the path taken by the request so far (e.g., a sequence of network addresses of devices through which the request has transited) and indicates the path that should be followed when routing the response. A header may also contain Record and Record-Route fields that are used to indicate that future requests and responses should be routed through an indicated device. Various network devices may insert Record-Route header fields when forwarding a SIP message in an attempt to force subsequent messages in a dialog to be routed through the device. The Record-Route header field may contain an identifier (e.g., network address) for the device and parameters. Devices that handle a message may force the message to be routed to devices listed in a message's Route header field. The Route header field values may be based on the Record-Route header field values inserted by devices. These and other header fields are described in the SIP specification referenced above.
A SIP server may be a single point of failure and may be unable to support large numbers of simultaneous sessions. The server could be a single point of failure because all SIP messages from or to a client may transit the server and, if the server fails, the client could be unable to participate in SIP dialogs because a location service may associate the client with the failed server. A single server may be unable to support large numbers of clients because of hardware (e.g., processor or memory) and network bandwidth limitations. In such cases, large numbers of clients can be denied server support, causing failure of the applications being performed on these clients.
An effective approach to overcome these disadvantages of SIP would have significant utility.
Approaches for efficiently routing messages using a pool of servers are provided. In an embodiment, the system attempts to ensure high availability of servers by enabling clients to specify a domain name for the server pool even though the server pool comprises multiple servers, each having a distinct name. When a client initiates a session by using the server pool's domain name, the system may select an available server with a different name, and will route the request and subsequent messages during the session to the selected server. The system may select a server from the pool having the lowest load. The system may also indicate servers that subsequent messages in the session are to transit. Subsequent messages may then be routed to indicated servers to enable application services on the indicated servers to take actions based on the messages and the direction of the messages.
In an embodiment, a system for efficiently routing messages using a pool of servers is provided. The system attempts to ensure high availability of a server by enabling a client to specify a single fully qualified domain name (“FQDN”) for the server pool even though the pool comprises multiple servers, each having a distinct FQDN. When a client initiates a SIP session by using the pool's FQDN, the system may select an available server (or “front end server”) from the pool, and will route the request and subsequent messages during the session to the selected server. The selected server's FQDN may be different from the server pool's FQDN. The system may select a server from the server pool that has the lowest load. Because subsequent messages will transit the selected server, the system may attempt to route messages directly to the selected server to minimize hops to other servers. If messages are not directly routed to the selected server, and are instead routed to other intermediate servers, the overall load of servers could increase because the servers are handling traffic unnecessarily. Moreover, overall message latency could also increase because of the additional hops. To enable direct routing of messages, the system modifies headers of messages by adding the FQDN of the selected server as a parameter to a header field of the request. Devices on a network may use this parameter to route messages directly to the selected server. The system may also add the FQDN of a registration server (e.g., registrar) of the recipient of the message as a parameter to a header field. Devices on the network may use this header field to communicate with the registration server to, e.g., locate information relating to the recipient. Devices routing the messages in compliance with the SIP specification will preserve these header fields and parameters in subsequent SIP messages exchanged during the session. By evaluating these header fields and parameters, network devices are able to route messages directly to the selected server and locate information stored in a registration server associated with the recipient. In a subsequent session, or if a session needs to be re-established because the selected server is no longer available (e.g., because it has crashed), the system is able to select another server for the client. Thus, the system is able to ensure high availability of servers and balance load across servers.
In an embodiment, to ensure that applications running on servers along the path of a message can correctly process transiting messages, the servers may add a flag to the message's header indicating a role for a server. As an example, a server on the path may record billing information relating to messages sent or received by a user. To ensure that the application notices all message traffic and is able to take appropriate action based on its role, the system adds a To/From flag to a message header field. By determining from the header field whether the server's role is to handle messages from or to the original sender of the session creation request, the application is able to take appropriate action without performing expensive database lookups to determine the server's role. Using parameters in a header field to indicate a server's role also enables the system to limit the servers that take application-related actions on messages. When this information appears as parameters of Record-Route header fields, SIP-complaint devices not controlled by the system will return the information. As a result of adding header fields and parameters that travel with the message, database or other lookups are avoided and messages are correctly processed.
In an embodiment, the system uses domain and device names that are not fully qualified. As examples, the system may use relative domain names or machine names. The system may be able to resolve or use these domain and device names to uniquely identify a server pool or device.
Turning now to the figures,
The server pools of the system may be coupled to a network 108. The network may be an intranet, Internet, or any other type of network. The network may also be coupled to one or more user devices 110. These user devices may use the network to exchange messages with a server pool.
The servers may also be coupled to other network resources, such as a database server 206. In an embodiment, each server 204 has its own database. Alternatively, the servers may use a database located at the database server. The database may reside either in a computing device separate from the server or in the same computing device as the server. The database may be used to store information relating to sessions. As an example, the database may be used to store a server's role for each session the server is handling.
The servers 204 may also be coupled to a load balancer 208. When a session creation request arrives at a load balancer, the load balancer may select a server from the server pool that will handle the request based on, e.g., the load on each server. As an example, if a server pool has three servers, and a server is down for maintenance, and one of the remaining two servers has high processor or network utilization, the load balancer may select the third server.
The server pool may be coupled to a proxy server 210. The proxy server takes various actions on messages it handles including, e.g., interpreting or modifying headers, forwarding the messages, and removing the messages from the network. The proxy server may have multiple network interfaces. One interface may be coupled to the Internet and another interface may be coupled to the server pool. When a server pool makes use of a proxy server, all traffic between clients and the server pool may transit the proxy server. Incoming request messages may first be handled by a proxy server, which validates routing information appearing in header fields of the request messages. The messages may then be forwarded to an enterprise services component, if one is present in the system (not shown), and then to other applications (not shown). These components may be performed by a server in a server pool.
Incoming response messages may also first be handled by a proxy server to validate routing information. The response messages may then be forwarded to applications (in reverse order as compared to request message handling), and then to the enterprise services component, if one is present. The proxy server may then update routing information before forwarding the response message.
At block 306, the routine determines whether the message arrived on a connection that is trusted. As examples, a connection is trusted when the connection uses Transport Layer Security (“TLS”) and the system has verified that the entity sending the message has a TLS certificate or alternatively that the connection has been marked by an administrator of the system as being trusted. TLS uses certificates to enable private digital communications between devices. The technique may use any technology to enable private communications including, e.g., Kerberos, Advanced Encryption Standard, or Data Encryption Standard. If the connection is trusted, the routine continues at block 310. Otherwise, the routine continues at block 308.
At block 308, the routine may process and modify some header fields. As an example, the routine may remove Record-Route header fields and header fields indicating the fully qualified domain name of an edge proxy. An edge proxy is a proxy server that straddles an intranet and the Internet (e.g., in a “demilitarized zone” or “DMZ”) such that a device on the Internet side of the edge proxy communicates with devices on the intranet only through the edge proxy. The system removes these header fields because it does not trust their validity as the connection was not trusted. If the proxy server does not remove the header fields, subsequent servers may erroneously trust the headers. When a connection cannot be trusted, the proxy server expects direct connections from clients, in which case, these header fields could not be present. When a client connects through another proxy, the connection would be trusted because the other proxy would be able to validate itself via TLS (or would have some other indication of a trusted connection). While processing the header fields, the routine may also determine whether the Request-URI is signed. If the Request-URI is not signed, the system may not be able to trust parameters indicating server roles or identifiers of specific servers in the server pool for the same reasons as indicated above, and so removes these parameters. The routine also validates Contact header fields by determining whether an IP address indicated for a contact in the message is the same IP address as that of the device sending the message. A Contact header field in a message contains a URI at which the sender of the message will receive requests.
At block 310, the routine determines whether the topmost Route header field has a “maddr” parameter whose value matches the IP address in the topmost Via header field. If the header field has a maddr parameter but the IP address indicated in the header field does not match the IP address of the entity sending the message, the routine replaces the IP address and port parameters relating to the FQDN identified in the header field with the IP address and port of the sender. The routine also adds a Received-CID URI parameter (e.g., to INVITE messages that initiate a dialog) to ensure that subsequent messages in the dialog will be sent through the correct connection. The Received-CID parameter may contain a unique number that is used to prevent a client from connecting to a dialog it did not previously participate in. As an example, if a client does not properly disconnect from a server and a new client connects to the same port of the server, the new client may be able to continue the dialog. However, the new client would not possess a correct Received-CID parameter because the server would not add it to a message. The incorrect Received-CID parameter would be an indication to the server that the new client does not belong to the dialog. If an edge proxy's FQDN (or that of a Network Address Translator) is indicated in a header field, the routine saves the FQDN and removes that header field to prevent it from traveling with the message into the server pool.
At block 312, the routine determines whether the connection in which the message was received is with a federated domain. A federated domain is a trusted domain other than the domain in which the proxy server operates. The routine may evaluate whether the connection is with a federated domain when the server performing the routine is an edge proxy. If the message is from a federated domain, the routine continues at block 314. Otherwise, the routine continues at block 316.
At block 314, the routine determines whether the Route header fields and Request-URI of the message have been digitally signed. If these fields have been digitally signed with a valid signature, the routine continues at block 316. Otherwise, the routine determines whether there are no Route header fields and whether the Request-URI is not digitally signed. If that is the case, the routine removes parameters in header fields indicating the server's role and continues at block 316. Otherwise, the routine continues at block 322. At block 322, the routine returns a response containing response code 481, which indicates that the user agent server has received a request that does not match an existing transaction (e.g., session). When a user agent client receives such a response, it may react by attempting to re-establish a session.
At block 316, the routine calls a Process_Header subroutine and at block 318, the routine calls an Application_Routing subroutine. These subroutines are described below in further detail in relation to
At block 406, the routine determines whether the FQDN in the topmost Route header field matches the FQDN of the server pool to which the server belongs. If the FQDNs match, the routine continues at block 408. Otherwise, the routine continues at block 420. At block 408, the routine extracts parameters from a Route header indicating the role of the server and an identification of the server to which the message will be routed.
At block 410, the routine extracts the server's role and an identification of the server to which the message will be routed from a Request-URI. These parameters may have been added to the Request-URI by an entity when that entity determined the role the proxy server processing the header will play. At block 412, the routine determines whether the parameter identifying the destination server indicates a server other than the server performing the routine. If that is the case, the routine continues at block 414. Otherwise, the routine continues at block 416. At block 414, if a parameter indicating the server's role was extracted, the role is stored in such a way that an application doing additional processing can retrieve information relating to the role, e.g., in a database coupled to the server. At block 416, the routine duplicates the topmost Route header such that it appears to have been inserted by the entity that sent the message to the server on which the routine is being performed. At block 420, the routine responds with a response code of 481, which indicates that the user agent server that received the request does not have a corresponding transaction (e.g., session). At block 418, the routine returns to its caller.
The routine may begin at block 548 when a server generates a NOTIFY message, or at block 502 in any other circumstance (e.g., when it processes a message). When a server generates a NOTIFY message, the routine begins performing at block 548. In such a case, the server's role may be implicitly set to “From.” A NOTIFY message is a message from a user agent to another indicating the state of a resource. At block 549, the routine determines whether the generated NOTIFY message already has Route headers. The server may have retrieved Route headers from a database and placed them in the generated NOTIFY message. If the NOTIFY message already has Route headers, the routine continues at block 508. Otherwise, the routine continues at block 528.
The routine may begin at block 502 where it receives a message as a parameter. At block 504, the routine determines whether the message is trusted for authentication. A message is trusted for authentication when it arrives on a TLS connection from another server in the same domain as the server performing the routine, on a TLS connection from an edge proxy that indicates the message is trusted, or in a connection marked as trusted by an administrator. As indicated above, the technique can be used with any technology that enables private communications. If the message is trusted for authentication, the routine continues at block 506. Otherwise, the routine continues at block 536.
At block 506, the routine determines whether Route headers are present in the message. The presence of Route header fields in the message indicates that a server has already indicated a next hop for the message or that the message is a part of an existing session for which a route (e.g., a sequence of hops) has already been established by prior messages, and so the server does not need to determine the next hop. In an embodiment, the server may also verify that it is not responsible for the URI indicated in the header of the message. If Route headers are present, the routine continues at block 508. Otherwise, the routine continues at block 512. At block 508, the routine calls an Other_Routing subroutine, which is further described below in relation to
At block 512, the routine determines whether role parameters were previously saved (e.g., by the proxy server, previous server handling the message, or by routing a prior message in the session). When such a parameter was previously saved, it is an indication to the routine that the server's role has previously been determined. If that is the case, the routine continues at block 514. Otherwise, the routine continues at block 528.
At block 514, the routine determines whether the server's role is “To.” If that is the case, the routine continues at block 516. Otherwise, the routine continues at block 524. At block 516, the routine determines whether the request's destination is a server of a “To” server pool. If that is the case, the routine continues at block 518. Otherwise, the routine continues at block 520. At block 518, the routine processes the request and may send a response.
At block 520, the routine determines whether a parameter indicating an endpoint identifier (“EPID”) is present in a header field of the message. An EPID can be used to distinguish multiple logins relating to a user (e.g., one from a desktop computing device and another from a cellular telephone). The presence of an EPID parameter indicates that an end point of the “To” server pool has already been selected because it is the “To” server that first adds an EPID parameter to messages, and this parameter is preserved in subsequent messages. If an EPID parameter is present, the routine continues at block 522. Otherwise, the routine continues at block 508. At block 522, the routine inserts Route headers in the message indicating that the next server is a “To” server. The server may also set its role to “To” unless the message will be routed to another server in the pool, in which case the server will add a parameter to the topmost Route header field to point to another server in the server pool.
At block 524, the routine determines whether the destination for the request is a “From” server. If that is the case, the routine continues at block 518. Otherwise, the routine continues at block 526. At block 526, the routine saves an indication that the server's role is “From.” At block 528, the routine determines whether the server is in the domain of the “To” server pool. If that is the case, the routine continues at block 530. Otherwise, the routine continues at block 508.
At block 530, the routine retrieves the FQDN of the “To” server pool. At block 532, the routine determines whether the server performing the routine is a member of the “To” server pool. If that is the case, the routine continues at block 516. Otherwise, the routine continues at block 534. At block 534, the routine adds the FQDN of the “To” server pool to the message's Request-URI with a parameter indicating that the next server is a “To” server. As a result, when the Request-URI is subsequently processed by a proxy server, the message will be sent to a server in the “To” server pool.
At block 536, the routine determines whether the message was authenticated. If the message was authenticated, the routine continues at block 538. Otherwise, the routine continues at block 546. At block 546, the routine requests the proxy server to challenge the message.
At block 538, the routine determines whether there are Route headers in the message, which indicates that the message is part of a dialog in an existing session. If that is the case, the routine continues at block 508. Otherwise, the routine continues at block 540.
At block 540, the routine retrieves the FQDN of the “From” server pool. At block 542, the routine determines whether the server performing the routine is a member of the “From” server pool. If that is the case, the routine continues at block 524. Otherwise, the routine continues at block 544. At block 544, the routine adds the FQDN of the “From” server pool to the Request-URI in the message's headers with a parameter indicating that the next server is a “From” server. When the Request-URI is subsequently processed by a proxy, the message will be sent to a server in the “From” server pool.
At block 606, the routine evaluates whether the next hop for the message can be determined from the header of the message. If there is a Route header field indicating a destination, the routine determines the FQDN or IP address for the next hop from the Route header. Otherwise, if a server of the server pool is identified in the Request-URI and the message is trusted for routing, the indicated server is used as the next hop. If that is not the case, and the Request-URI matches a pattern in a static routing table associated with the server, the next hop is retrieved from the static routing table. The message is trusted for routing when it is received in a trusted connection or its Request-URI was modified by an application installed on the server, or the routing information is digitally signed. If the message is trusted for routing, the routine identifies the host portion of the Request-URI in the message's header as the next hop. If the next hop cannot be determined, the routine continues at block 620. Otherwise, at block 608, the routine resolves the FQDN or IP number of the determined next hop, and connects to the identified entity (or uses an already-open connection).
At block 610, the routine determines whether the FQDN could be resolved and a connection is open. If that is the case, the routine continues at block 612. Otherwise, the routine continues at block 620. At block 612, the routine determines whether the request was generated locally and whether a Record-Route is needed. A Record-Route is needed on edge proxies, forwarding proxies, when a server role parameter is saved, and in some other circumstances. A Record-Route is not needed for messages that do not initiate a dialog, such as NOTIFY, MESSAGE, INFO, and SERVICE message types. If the message was not generated locally or a Record-Route is needed, the routine continues at block 614. Otherwise, the routine continues at block 616.
At block 614, the routine may add header fields or parameters to the message. Which headers and parameters are added may depend on whether the connection in which the message will be sent is marked as “one-way.” An administrator may enable a device for only one-way connections (e.g., the device cannot accept connection requests from other devices) to, e.g., make the device more secure. When a connection is marked as “one-way,” the routine may add to a Record-Route header field of the message the server's FQDN, and port and IP address information, which enable the recipient of the message to use the connection established by the device for the session when returning a message. If the connection is not marked as one-way and the device performing the routine is a server of a server pool, the routine adds the server pool's FQDN to a Record-Route header field with a parameter identifying the server (e.g., the server's own FQDN or simply the server's name relative to the domain). When a subsequent message is received by the system in the session, the system could determine to which server to route the subsequent message based on the parameter. When the connection is not marked as one-way and the device performing the routine is not in a server pool, the routine determines whether the device is an edge proxy and the request message being evaluated originated at a client or forwarding proxy. If that is the case, the routine may add header fields and parameters similar to those added when the connection is marked as one-way so that subsequent messages are routed through the same edge proxy. Otherwise, the routine may add the server's FQDN to a Record-Route header field. If the device is an edge proxy, the device may add a FQDN that can be resolved by the device to which the message will be forwarded (i.e., a FQDN that can be resolved inside or outside an intranet depending on whether the next server is inside or outside the intranet). After adding these header fields, the routine may additionally add a parameter reversing the server's role (e.g., From to To or vice versa) if the opposite parameter was previously stored.
At block 616, the routine forwards the message. Before forwarding the message, the routine determines whether the connection on which the message will be sent is trusted for routing. As examples, connections using TLS (or some other mechanism enabling private communication) or explicitly indicated to be trusted by an administrator are trusted for routing. If the connection is trusted for routing and the process is being performed by an edge proxy, the routine determines whether the connection is with a federated domain. A federated domain is a trusted domain other than the server's domain. If the connection is not trusted or the connection is with a federated domain, the routine digitally signs any Contact and Record-Route header fields in the message and places signatures in the topmost Record-Route header field. Via headers are also digitally signed. The routine then forwards the message. At block 618, the routine returns to its caller. At block 620, the routine responds with a 504 response code, which indicates that the server did not receive a timely response when attempting to process the request.
At block 708, the routine determines whether the connection in which the message was received is trusted for routing. Circumstances in which a connection are trusted for routine are described above, e.g., in relation to
At block 710, the routine processes Record-Route header fields. The routine removes Record-Route header fields, if any, indicating the server performing the routine if there is no Contact header in the response. The routine may also remove other related header fields that it or another proxy may have inserted when processing the prior request that resulted in the present response. The routine may also add parameters to headers indicating the role of the server (or use values of removed parameters) so that the role can be identified or used when the sender of the prior request sends a subsequent request. The routine checks whether an administrator marked the connection as one-way. A one-way connection is an indication that other devices in the network cannot resolve the FQDN of the server or establish a connection back to the server. As an example, an administrator may desire to make a server a firewall, which enables outgoing connections but no incoming connections. If the connection is marked as one-way, the routine may add the server's FQDN, IP address, and port information to a Record-Route header field of the response. The routine may also use a forward-point parameter from a prior hop's Via header field to handle issues relating to transiting network address translators.
If the connection is not marked as one-way and the device performing the routine is a server of a server pool, the routine adds the server pool's FQDN to a Record-Route header field with a parameter indicating the server's FQDN. When a subsequent message is received by the system in the session, the system could determine to which server to route the subsequent message based on the parameter. When the connection is not marked as one-way and the device performing the routine is not in a server pool, the routine determines whether the device is an edge proxy and the request message being evaluated originated at a client or forwarding proxy. If that is the case, the routine may add header fields and parameters similar to those added when the connection is marked as one-way, so that subsequent messages are routed through the same edge proxy. Otherwise, the routine may add the server's FQDN to a Record-Route header field. If the device is an edge proxy, the device may add a FQDN that can be resolved by the device to which the message will be forwarded. After adding these header fields, the routine may additionally add a parameter reversing the server's role (e.g., From to To or vice versa) if the opposite parameter was previously stored.
At block 712, the routine removes the topmost Via header field. At block 714, the routine forwards the response. If the outgoing connection is trusted for routing (e.g., because it is using TLS or some other mechanism that enables private communications, or is indicated to be trusted by an administrator), the routine determines whether the connection is to a federated domain. If the connection is to a federated domain, the routine digitally signs header fields containing Record-Route and contact information. The routine also signs these header fields if the outgoing connection is not trusted for routing. The routine then forwards the response to the next entity in the response's route. At block 716, the routine returns to its caller.
The computing device on which the system for efficiently routing messages is implemented may include a central processing unit, memory, input devices (e.g., keyboard and pointing devices), output devices (e.g., display devices), and storage devices (e.g., disk drives). The memory and storage devices are computer-readable media that may contain instructions that implement the security system. In addition, the data structures and message structures may be stored or transmitted via a data transmission medium, such as a signal on a communications link. Various communications links may be used, such as the Internet, a local area network, a wide area network, or a point-to-point dial-up connection.
The security system may be described in the general context of computer-executable instructions, such as program modules, executed by one or more computers or other devices. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform particular tasks or implement particular abstract data types. Typically, the functionality of the program modules may be combined or distributed as desired in various embodiments.
From the foregoing, it will be appreciated that specific embodiments of the invention have been described herein for purposes of illustration, but that various modifications may be made without deviating from the spirit and scope of the invention. Accordingly, the invention is not limited except as by the appended claims.
|Brevet cité||Date de dépôt||Date de publication||Déposant||Titre|
|US5774660 *||5 août 1996||30 juin 1998||Resonate, Inc.||World-wide-web server with delayed resource-binding for resource-based load balancing on a distributed resource multi-node network|
|US6275937 *||26 nov. 1997||14 août 2001||International Business Machines Corporation||Collaborative server processing of content and meta-information with application to virus checking in a server network|
|US6389532 *||20 avr. 1998||14 mai 2002||Sun Microsystems, Inc.||Method and apparatus for using digital signatures to filter packets in a network|
|US6434143 *||8 nov. 1999||13 août 2002||Mci Worldcom, Inc.||Internet protocol telephony voice/video message deposit and retrieval|
|US6553422 *||26 avr. 1999||22 avr. 2003||Hewlett-Packard Development Co., L.P.||Reverse HTTP connections for device management outside a firewall|
|US6567915 *||23 oct. 1998||20 mai 2003||Microsoft Corporation||Integrated circuit card with identity authentication table and authorization tables defining access rights based on Boolean expressions of authenticated identities|
|US6584567 *||30 juin 1999||24 juin 2003||International Business Machines Corporation||Dynamic connection to multiple origin servers in a transcoding proxy|
|US6601099 *||26 nov. 1999||29 juil. 2003||Telefonaktiebolaget Lm Ericsson (Publ)||Method for extending the use of SIP (session initiation protocol)|
|US6865681 *||29 déc. 2000||8 mars 2005||Nokia Mobile Phones Ltd.||VoIP terminal security module, SIP stack with security manager, system and security methods|
|US6963635 *||6 mai 2003||8 nov. 2005||Sprint Spectrum L.P.||Method and system for facilitating collection of subscriber past due balance|
|US7010727 *||12 juin 2002||7 mars 2006||Nortel Networks Limited||Method and system for negotiating compression techniques to be utilized in packet data communications|
|US7085829 *||31 déc. 2001||1 août 2006||Innomedia, Pte Ltd.||Method and system for an intelligent proxy server for workload balancing by workload shifting|
|US7142537 *||18 déc. 2003||28 nov. 2006||Motorola, Inc.||Interface call signaling protocol|
|US7146417 *||12 sept. 2001||5 déc. 2006||Cisco Technology, Inc.||System for distributing load over multiple servers at an internet site|
|US7227868 *||21 mars 2002||5 juin 2007||Fujitsu Limited||Relay connection management program, relay connection management method, relay connection management apparatus and recording medium which stores relay connection management program|
|US7243370 *||17 mai 2002||10 juil. 2007||Microsoft Corporation||Method and system for integrating security mechanisms into session initiation protocol request messages for client-proxy authentication|
|US7382881 *||6 déc. 2002||3 juin 2008||Telefonaktiebolaget L M Ericsson (Publ)||Lawful interception of end-to-end encrypted data traffic|
|US7412521 *||12 mars 2003||12 août 2008||Microsoft Corporation||End-point identifiers in SIP|
|US7421732 *||5 mai 2003||2 sept. 2008||Nokia Corporation||System, apparatus, and method for providing generic internet protocol authentication|
|US7535905 *||31 mars 2004||19 mai 2009||Microsoft Corporation||Signing and validating session initiation protocol routing headers|
|US20020010798 *||16 févr. 2001||24 janv. 2002||Israel Ben-Shaul||Differentiated content and application delivery via internet|
|US20020129236 *||29 déc. 2000||12 sept. 2002||Mikko Nuutinen||VoIP terminal security module, SIP stack with security manager, system and security methods|
|US20020141404 *||12 déc. 2001||3 oct. 2002||Michael Wengrovitz||Call routing using information in session initiation protocol messages|
|US20020174125 *||22 oct. 2001||21 nov. 2002||Microsoft Corporation||Messaging infrastructure for identity-centric data access|
|US20020178240 *||24 mai 2001||28 nov. 2002||International Business Machines Corporation||System and method for selectively confirming digital certificates in a virtual private network|
|US20020184521 *||22 oct. 2001||5 déc. 2002||Microsoft Corporation||Authorizing a requesting entity to operate upon data structures|
|US20030005280 *||17 mai 2002||2 janv. 2003||Microsoft Corporation||Method and system for integrating security mechanisms into session initiation protocol request messages for client-proxy authentication|
|US20030009570 *||3 juil. 2001||9 janv. 2003||International Business Machines Corporation||Method and apparatus for segmented peer-to-peer computing|
|US20030012149 *||12 sept. 2002||16 janv. 2003||Qualcomm, Inc.||System and method for providing group communication services|
|US20030084331 *||26 oct. 2001||1 mai 2003||Microsoft Corporation||Method for providing user authentication/authorization and distributed firewall utilizing same|
|US20030105962 *||30 nov. 2001||5 juin 2003||Khiem Le||Apparatus, and associated method, for facilitating authentication of a mobile station with a core network|
|US20030110257 *||10 déc. 2002||12 juin 2003||Wook Hyun||Method for performing a load distribution between session initiation protocol servers within an intra domain|
|US20030217165 *||17 mai 2002||20 nov. 2003||Microsoft Corporation||End-to-end authentication of session initiation protocol messages using certificates|
|US20040024881 *||31 juil. 2002||5 févr. 2004||Elving Christopher H.||System and method for sticky routing of requests within a server farm|
|US20040043756 *||21 févr. 2003||4 mars 2004||Tao Haukka||Method and system for authentication in IP multimedia core network system (IMS)|
|US20040088424 *||18 juin 2003||6 mai 2004||Park Mi Ryong||SIP-based load balancing apparatus and method|
|US20040128554 *||8 sept. 2003||1 juil. 2004||Netrake Corporation||Apparatus and method for allowing peer-to-peer network traffic across enterprise firewalls|
|US20040205192 *||12 mars 2003||14 oct. 2004||Microsoft Corporation||End-point identifiers in SIP|
|US20040225878 *||5 mai 2003||11 nov. 2004||Jose Costa-Requena||System, apparatus, and method for providing generic internet protocol authentication|
|US20040246991 *||22 août 2003||9 déc. 2004||Hitachi Communication Technologies, Ltd.||IP address translator and packet transfer apparatus|
|US20040249911 *||31 mars 2003||9 déc. 2004||Alkhatib Hasan S.||Secure virtual community network system|
|US20040258239 *||13 juil. 2004||23 déc. 2004||Gallant John K.||Method and system for dynamic gateway selection in an IP telephony network|
|US20040260752 *||19 juin 2003||23 déc. 2004||Cisco Technology, Inc.||Methods and apparatus for optimizing resource management in CDMA2000 wireless IP networks|
|US20050005030 *||15 juin 2004||6 janv. 2005||Arito Asai||Peer-to-peer communications system and computer readable medium|
|US20050033985 *||26 juil. 2003||10 févr. 2005||Innomedia Pte Ltd.||Firewall penetration system and method for real time media communications|
|US20050286542 *||25 août 2005||29 déc. 2005||Shores William N||Interface call signaling protocol|
|US20060146766 *||27 févr. 2004||6 juil. 2006||Masayuki Nakajima||Radio terminal session control and interface set up method|
|US20070291743 *||13 juin 2007||20 déc. 2007||Alcatel Lucent||Detection of loops within a sip signalling proxy|
|US20080022383 *||4 juin 2007||24 janv. 2008||Microsoft Corporation||Method and system for integrating security mechanisms into session initiation protocol request messages for client-proxy authentication|
|Brevet citant||Date de dépôt||Date de publication||Déposant||Titre|
|US7506369 *||27 mai 2004||17 mars 2009||Microsoft Corporation||Secure federation of data communications networks|
|US7535905||31 mars 2004||19 mai 2009||Microsoft Corporation||Signing and validating session initiation protocol routing headers|
|US7664108 *||9 oct. 2007||16 févr. 2010||Abdullah Ali Bahattab||Route once and cross-connect many|
|US7761538||30 août 2006||20 juil. 2010||Microsoft Corporation||Dynamically configuring, allocating and deploying computing systems|
|US8024476||21 mai 2004||20 sept. 2011||Microsoft Corporation||Efficient message routing when using server pools|
|US8040881 *||17 avr. 2007||18 oct. 2011||Canon Kabushiki Kaisha||Communication apparatus and control method of the apparatus|
|US8112796||9 janv. 2009||7 févr. 2012||Microsoft Corporation||Secure federation of data communications networks|
|US8275885 *||6 févr. 2008||25 sept. 2012||International Business Machines Corporation||Method, apparatus and system for processing a series of service messages|
|US8364824 *||30 mai 2008||29 janv. 2013||International Business Machines Corporation||Reducing the learning curve of a transmission control protocol connection|
|US8412830||24 oct. 2007||2 avr. 2013||International Business Machines Corporation||Method and apparatus for improving SIP parse performance|
|US8589567||14 sept. 2012||19 nov. 2013||International Business Machines Corporation||Method and apparatus for improving SIP parse performance|
|US8620989||1 déc. 2006||31 déc. 2013||Firestar Software, Inc.||System and method for exchanging information among exchange applications|
|US8713186 *||12 mars 2008||29 avr. 2014||Oracle International Corporation||Server-side connection resource pooling|
|US8838668 *||1 déc. 2006||16 sept. 2014||Firestar Software, Inc.||System and method for exchanging information among exchange applications|
|US8838737||18 août 2011||16 sept. 2014||Firestar Software, Inc.||System and method for exchanging information among exchange applications|
|US8856279 *||22 mai 2006||7 oct. 2014||Citrix Systems Inc.||Method and system for object prediction|
|US8867536||19 sept. 2011||21 oct. 2014||Canon Kabushiki Kaisha||Communication apparatus conditional notification destination registration|
|US8929360 *||14 nov. 2007||6 janv. 2015||Cisco Technology, Inc.||Systems, methods, media, and means for hiding network topology|
|US8943181 *||28 nov. 2006||27 janv. 2015||Ebay Inc.||Method and system for reducing connections to a database|
|US20050220095 *||31 mars 2004||6 oct. 2005||Sankaran Narayanan||Signing and validating Session Initiation Protocol routing headers|
|US20050265327 *||27 mai 2004||1 déc. 2005||Microsoft Corporation||Secure federation of data communications networks|
|US20060048163 *||27 août 2004||2 mars 2006||Thierry Bessis||Method for routing messages between servers located on the same board|
|US20060083242 *||22 nov. 2004||20 avr. 2006||Nokia Corporation||Address modification in application servers|
|US20060271641 *||22 mai 2006||30 nov. 2006||Nicholas Stavrakos||Method and system for object prediction|
|US20070136311 *||28 nov. 2006||14 juin 2007||Ebay Inc.||Method and system for reducing connections to a database|
|US20070198437 *||1 déc. 2006||23 août 2007||Firestar Software, Inc.||System and method for exchanging information among exchange applications|
|US20080137686 *||14 nov. 2007||12 juin 2008||Starent Networks Corporation||Systems, methods, media, and means for hiding network topology|
|US20080228923 *||12 mars 2008||18 sept. 2008||Oracle International Corporation||Server-Side Connection Resource Pooling|
|US20080228931 *||30 mai 2008||18 sept. 2008||International Business Machines Corporation||Method to Reduce the Learning Curve of a Transmission Control Protocol Connection|
|US20090185673 *||23 juil. 2009||Avaya Technology Llc||Voice-Over-IP Call Recording in Call Centers|
|US20120005370 *||30 juin 2010||5 janv. 2012||Aleksandr Stolyar||Methods of routing for networks with feedback|
|WO2008049853A2||24 oct. 2007||2 mai 2008||Ibm||Methods, apparatuses and computer program for improving sip parse performance|
|Classification aux États-Unis||709/228|
|Classification internationale||G06F9/50, H04L29/08, H04L12/56, G06F15/16, G06F11/20, H04L29/12, H04L29/06, G06F15/00, G06F13/00|
|Classification coopérative||H04L65/1006, H04L61/15, H04L29/06027, H04L29/12047, H04L63/166, H04L67/101, H04L67/1002, H04L67/1008, H04L69/22|
|Classification européenne||H04L29/08N9A1B, H04L63/16D, H04L29/06N, H04L29/06C2, H04L29/08N9A, H04L29/06M2H2|
|21 mai 2004||AS||Assignment|
Owner name: MICROSOFT CORPORATION, WASHINGTON
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:EYDELMAN, VADIM;SHOROFF, SRIKANTH;REEL/FRAME:015373/0628
Effective date: 20040519
|9 déc. 2014||AS||Assignment|
Owner name: MICROSOFT TECHNOLOGY LICENSING, LLC, WASHINGTON
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MICROSOFT CORPORATION;REEL/FRAME:034541/0477
Effective date: 20141014
|1 mai 2015||REMI||Maintenance fee reminder mailed|