Network communication systems and methods

Systems and methods for communicating via a network may employ communication devices capable of functioning in a server mode and a client mode. Communication may begin by activating a server mode for a first communication device. The first communication device in the server mode may receive a message from a second communication device, the message comprising an identity associated with the second communication device. The first communication device may retrieve a key associated with the second communication device and verify the identity associated with the second communication device by comparing data in the message from the second communication device with data in the key. A client mode may be activated for the first communication device. The first communication device in client mode may send a message to an address associated with the second communication device, the message comprising an identity associated with the first communication device.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1depicts a network according to an embodiment of the invention.

FIG. 2depicts a set of communication protocol instructions according to an embodiment of the invention.

FIG. 3Adepicts a communication start up process according to an embodiment of the invention.

FIG. 3Bdepicts a start up graphical user interface (GUI) according to an embodiment of the invention.

FIG. 4Adepicts a login process according to an embodiment of the invention.

FIG. 4Bdepicts a login GUI according to an embodiment of the invention.

FIG. 5depicts a server start up process according to an embodiment of the invention.

FIG. 6depicts a GUI according to an embodiment of the invention.

FIG. 7depicts a GUI according to an embodiment of the invention.

FIG. 8depicts an address retrieval process according to an embodiment of the invention.

FIG. 9depicts a GUI according to an embodiment of the invention.

FIG. 10depicts a GUI according to an embodiment of the invention.

FIG. 11depicts a registration process according to an embodiment of the invention.

FIG. 12depicts a connection process according to an embodiment of the invention.

FIG. 13depicts a network according to an embodiment of the invention.

FIG. 14depicts a network according to an embodiment of the invention.

FIG. 15depicts a network according to an embodiment of the invention.

FIG. 16depicts a network according to an embodiment of the invention.

FIG. 17depicts a network according to an embodiment of the invention.

FIG. 18depicts a network according to an embodiment of the invention.

FIG. 19depicts a network according to an embodiment of the invention.

FIG. 20depicts a network according to an embodiment of the invention.

FIG. 21depicts a network according to an embodiment of the invention.

FIG. 22depicts a network according to an embodiment of the invention.

FIG. 23depicts a network according to an embodiment of the invention.

FIG. 24depicts a network according to an embodiment of the invention.

FIG. 25depicts a network according to an embodiment of the invention.

FIG. 26depicts a network according to an embodiment of the invention.

FIG. 27depicts a network according to an embodiment of the invention.

FIG. 28depicts a network according to an embodiment of the invention.

FIG. 29depicts a network according to an embodiment of the invention.

FIG. 30depicts a network according to an embodiment of the invention.

FIG. 31depicts a network according to an embodiment of the invention.

FIG. 32depicts a network according to an embodiment of the invention.

FIG. 33depicts a network according to an embodiment of the invention.

FIG. 34depicts a communication process according to an embodiment of the invention.

FIG. 35depicts a connection process according to an embodiment of the invention.

DETAILED DESCRIPTION OF SEVERAL EMBODIMENTS

Systems and methods for using inter-carrier interfaces (ICIs) to enable communication devices, such as Internet protocol (IP) compatible devices, to communicate with one another are described herein. In some embodiments, communication devices used with an ICI may be computers. A computer may be any programmable machine capable of performing arithmetic and/or logical operations. In some embodiments, computers may comprise processors, memories, data storage devices, and/or other commonly known or novel components. These components may be connected physically or through network or wireless links. Computers may also comprise software which may direct the operations of the aforementioned components. Computers may be referred to with terms that are commonly used by those of ordinary skill in the relevant arts, such as servers, PCs, mobile devices, and other terms. It will be understood by those of ordinary skill that those terms used herein are interchangeable, and any computer capable of performing the described functions may be used. For example, though the term “server” may appear in the following specification, the disclosed embodiments are not limited to servers. Specific examples of computers that may be used as communication devices include voice over Internet protocol (VOIP) phones, smartphones, personal computers (PCs), tablets, and/or other devices.

Computers may be linked to one another via a network or networks. A network may be any plurality of completely or partially interconnected computers wherein some or all of the computers are able to communicate with one another. It will be understood by those of ordinary skill that connections between computers may be wired in some cases (i.e. via wired TCP connection or other wired connection) or may be wireless (i.e. via WiFi network connection). Any connection through which at least two computers may exchange data can be the basis of a network. Furthermore, separate networks may be able interconnected such that one or more computers within one network may communicate with one or more computers in another network. In such a case, the plurality of separate networks may optionally be considered to be a single network.

FIG. 1depicts a network100according to an embodiment of the invention. More specifically, the large-scale network100comprises a plurality of interconnected networks, including the Internet110and two local networks120. Individual computers may be connected to the local networks120. For example, a computer comprising Session Initiation Protocol (SIP) software (a SIP softphone)130may be connected to the Atlanta local network120, and a computer specialized for SIP use (a SIP hardphone)140, such as a VOIP phone or smartphone, may be connected to the Biloxi local network120. SIP is a signaling protocol for creating, modifying, and terminating multi-media sessions with one or more peer-to-peer participants. The voice and video stream communications in SIP calls may be transported by a Real-time Transport Protocol (RTP). SIP signaling procedures may include setting up parameters for an RTP media stream such as IP address, port number, protocol, codecs, etc. The parameters may be exchanged and negotiated using a Session Description Protocol (SDP) which may be embedded within SIP signaling information.

In this example, each of the local networks120is connected to the Internet110through a Network Address Translation (NAT) device150or other type of gateway. A NAT device150may be deployed at an interface between a public and private network. A NAT device150may translate IP addresses and ports between the addresses and ports used by a public network (i.e. the Internet110) and the addresses and ports used by a private network (i.e. the local networks120). A NAT device150may allow computers on a private network to communicate via the public network while masking the computer's private address to other computers outside the private network. NAT devices150may also have various security measures such as firewalls in place to prevent and/or restrict undesirable access to computers inside the private network. In other network embodiments without NAT devices150, security measures such as firewalls may still be used at interfaces between public and private networks.

When security measures are in place between networks, communications from computers associated with one network must be able to traverse these measures in order to communicate with other computers outside the network. For example, in order for the SIP softphone130associated with the Atlanta network120to send data to the SIP hardphone140associated with the Biloxi network120, the data must traverse each NAT150associated with each of the private networks120. ICI software and/or hardware160may be associated with each of the private networks120. In the following discussion, “ICI” will be used to indicate any hardware and/or software capable of communicating through an inter-carrier interface. The ICI160may enable communication between computers between the private networks120using an ICI protocol170. The systems and methods described herein may enable secure SIP communications over a public or private IP network using PKI (Public Key Infrastructure) security measures.

The ICI160may enable data connections between devices that may be on separate networks. These connections may be used to transmit voice, video, audio, and/or any other type of data. Each device may have an associated public address and private address, which may be IP addresses or addresses associated with other protocols. For example, a device associated with a private network120may have a private address that may used within the private network120and that private address may be masked from outside networks by a NAT150or other device. The NAT150or other device may use a public address to allow and/or restrict interaction by the device on the private network with computers outside the network. As will be described in greater detail below, the ICI160, before sending protocol information to a remote SIP device140on behalf of a local SIP device130during a protocol negotiation session, may securely replace a private IP address of the local SIP device130with a public IP address of a local NAT150. This may allow the remote SIP device140to send data to the local NAT150, using its public IP address. The NAT150may then deliver the data to the local SIP device130. Any individual ICI160may be able to act as a client and/or a server when establishing a connection to another ICI160.

FIG. 2depicts a set of communication protocol instructions according to an embodiment of the invention. SIP protocol instructions270and ICI protocol instructions200that may be compatible with the SIP protocol instructions270are shown in this example. A SIP communication session for a pair of SIP devices such as a SIP softphone130and SIP hardphone140may be performed when both devices130,140carry out the SIP protocol instructions270. When no ICI160is used, a SIP session may proceed as follows. Both devices130,140may register205with a network and receive confirmation210that they have registered. A source device (here, the SIP softphone130) may send an invite215to a target device (here, the SIP hardphone140), which may receive the invite215. In response, the target device140may begin trying to establish communication220and may ring225. The target device140may inform the source device130that it is trying220and ringing225. If connection is successful on the target device140end (for example due to a user answering the ringing phone140), the target device140may inform the source device130that the attempt was successful230. The source device130may transmit an acknowledgement235, and a media session250may begin. The media session250may enable communication of data such as voice, audio, and/or video information between the connected devices130,140. When the media session250ends (for example due to a user hanging up one of the phones, such as the SIP hardphone140in this case), the device ending the session140may transmit a message indicating the end of the session255, and the other device130may acknowledge the message260. In some embodiments, some of the messages described above may be omitted and/or others may be added.

In communication systems and methods employing ICI160, an ICI protocol170may carry some or all of the messages described above between SIP devices. For example, the SIP devices130,140may register205with and be acknowledged210by ICI systems160on their respective networks120. Then, the remaining communications described above may be handled by an ICI session200. Communications originating with or intended for the SIP devices130,140may be transmitted and/or received by ICIs160. As seen inFIG. 2, all of the messages associated with the SIP protocol may be handled by the ICI system160. In some embodiments, some of the messages described above may be omitted and/or others may be added.

A basic ICI connection process between two devices may proceed as follows. Certificates containing public keys associated with each of the two devices may be exchanged by the devices. For example, a public key infrastructure (PKI) may be used to generate and/or exchange keys. These certificates may be exchanged through any electronic communication medium. Each of the ICIs160may import the certificate from the other ICI160to a trust store. Each ICI160may have its own trust store. Public keys contained in a trust store may be used to establish trust when connections are being made. For example, a first ICI160may only connect to a second ICI160or accept connections from the second ICI160if the first ICI160has the second ICI160's public key in its trust store. Each ICI160may obtain a public IP address associated with the other ICI160, which may be for example a public IP address associated with a NAT device protecting a private network to which an ICI160and a communication device are connected. The public IP address may be obtained from an IP lookup website in some embodiments. Public IP addresses may be exchanged through any communication medium, for example via emails between users of the devices or the like. Each ICI160may locally register the other ICI160by storing data such as device name, public IP address, and/or other data. Each ICI160may also register associated communication devices. ICIs160that are mutually registered may connect to and communicate with one another through an ICI connection, thereby enabling communication between associated communication devices. For example, a first device may request a connection to a second device. The request may create an open port in a local NAT device associated with the second ICI160, and the request may be received by the second ICI160. A communication channel may then be established between the two ICIs160. Each ICI160in a connection may obtain the public key of the other ICI160and store it in a local trust store. An ICI connection attempt may be aborted if both parties to a connection do not have each other's keys. Subsets and embodiments of ICI systems and processes are described in greater detail below.

A plurality of communication and display devices that use SIP or some other technology with an ICI160may be considered a SIP network. In some embodiments, a SIP network may be associated entirely with a single local network120. In a SIP network, SIP devices may register with one or more ICIs160so that they may send and/or receive SIP VoIP calls or other communications. When the call arrives, for example from a second phone on a second network120to a first phone on a first network120, an ICI160associated with the first phone may send the call to the first phone using an IP address that was collected through a registration process, such as the registration process described in greater detail below. ICIs160may register SIP phones and create a SIP network of phones behind a NAT/firewall, use SIP outbound proxy service, from behind a NAT/firewall, to validate PKI public keys and to establish mutual inclusive connections with other SIP networks of phones, and/or build distributed, scalable, secure, and privacy protected communication networks.

Each SIP network may manage its associated SIP phones and AORs in a distributed architecture fashion. For example, an ICI160for a SIP network may control its own network activities such as adding or deleting AORs, selecting SIP phone models and the call services that the phones can provide, and/or performing other management functions. A SIP network may be added to a larger network of SIP networks without requiring centralized registry or administration. For example, a SIP network in communication with the Internet may be linked to other SIP networks through ICI protocol170connections, as will be described in greater detail below. SIP networks may be deployed or removed without interrupting services of the Internet or other SIP networks.

Security may be provided by Public Key Infrastructures (PKI) and NAT/firewall hardware and/or software. A PKI pair of keys, the private key and public key, may be created by an ICI160. The public key may be self-signed and may be distributed to other ICIs160so that connections may be established between ICIs160. A private key may be kept for local use and may be undistributed. In systems and networks employing self-signed public keys, verification may be performed without the use of a central registry. For example, if both ICIs160in a two-way communication attempt have each other's certificates, a connection may be successful, and if one or both ICIs do not have the certificate of the other, the connection may be refused, as will be described in greater detail below. ICIs160may exchange their PKI certificates and import the certificates of other ICIs to their own truststores. Truststores may be databases associated with ICIs160. The truststores may be protected from external access by NAT/firewall hardware or software or other means. The truststores may be encrypred.

Processes for enabling and establishing ICI communications may be considered from the perspective of an individual ICI160. It will be understood that in order for communication between a plurality of devices to take place, each of the plurality of devices may perform some or all of the following processes and/or additional processes.

FIG. 3Adepicts a communication start up process300according to an embodiment of the invention. When an ICI device (which may be an ICI160, a communication device130,140on a network associated with an ICI160, or a combination thereof) attempts to start a communication process, it may look for a previously established database associated with the ICI device310. The database may contain such data as usernames, passwords, private keys, and/or public key certificates associated with the ICI device. If such a database exists320, the ICI device may present a login interface, such as a graphical user interface (GUI), to a user400, described in greater detail with respect toFIGS. 4A-4Bbelow. The user may use this interface to login and start the ICI process500. If no database exists320(or if a user requests to create a new username and/or password in some embodiments), the ICI device may present a startup interface to a user330. For example,FIG. 3Bdepicts an example start up GUI305according to an embodiment of the invention. As seen in this example GUI305, a user may be able to enter information such as a username and password. Returning toFIG. 3A, the ICI device may receive an inputted username and password340and create a secure database using the password350. The ICI device may create a private key360, a keystore to store the private key370, and a public key certificate380which may include a public key. Then the device may start the ICI process500.

FIG. 4Adepicts a login process400according to an embodiment of the invention. Upon initiation of a login process400, the ICI device may present a login interface, such as a graphical user interface (GUI), to a user410. For example,FIG. 4Bdepicts an example login GUI405according to an embodiment of the invention. As seen in this example GUI405, a user may be able to enter a login password associated with the ICI device and/or a username. Returning toFIG. 4A, the ICI device may receive an inputted password420and use the password to login to the database430. A password may be determined to be valid440if the password is found in the database and corresponds with the ICI device and/or provided username. If the password is valid440, an ICI process500may begin. If the password is invalid440, access to the ICI process may be denied and the login GUI may be displayed410(or some other message or interface may be displayed).

FIG. 5depicts a server start up process500for the ICI device according to an embodiment of the invention. An ICI device may be both a client and a server when communicating via ICI systems and methods. For example, when the ICI device is sending information it may function as a client, and when the device is receiving information it may function as a server. Therefore, when the ICI process begins500, the ICI device may establish itself as a server so that it may listen and/or wait for another device to try to connect to it. Using the information in the keystore, the server device may create a secure socket layer context object (SSLContext)510. The server device may use the SSLContext to create a secure socket layer engine object (SSLEngine)520. The SSLEngine may enable the server device to transmit and/or receive secure communications. SSLContexts and/or SSLEngines may be created using Java SSL programming and methods or in some other way. Those of ordinary skill in the relevant art will appreciate that in embodiments not using Java, similar functionality to that provided by SSLContext and/or SSLEngine objects may be provided using various hardware and/or software combinations. The SSLEngine of this example may have a setting such as a “use client mode” bit flag that may indicate whether the device is set to use a client mode or a server mode. To function in a server mode, the server device may set this “use client mode” selection to false530or otherwise indicate that it will function in server mode. To ensure that other devices attempting to connect to the server device have any necessary security authorization, the server device may set a “need client authentication” setting of the SSLEngine to true540or otherwise indicate that client authentication is needed. If client authentication is needed, the server device may verify that any client attempting to connect to the server is registered with the server. This may be done by checking for the attempting client's public key in the server's trust store, for example. After the client authentication setting is made540, the server device may be ready for incoming connection requests550.

FIG. 6depicts a GUI600according to an embodiment of the invention. This GUI600may be presented to a user of an ICI device after login, and in some embodiments after the device is placed in server mode and made ready for incoming connections as described above. This GUI600is one example of an interface that may enable a user to interact with the device, but other interfaces, including those that are not GUIs, may be possible. As seen in this example, a GUI600may allow a user to change a password, verify a certificate as being trustworthy, import a certificate to the trust store, view certificates in the trust store, delete certificates in the trust store, manage connectivity, register hardware and/or address, and/or perform other tasks. Note that in some embodiments, a password used to login may be different from a password used to access the trust store. A GUI600may allow a user to change one or both of these passwords.

FIG. 7depicts a GUI600according to an embodiment of the invention. As seen in this view, the GUI600may enable network connection and other network function management. For example, the GUI600may display information about the local network and/or other networks. The GUI600may also enable a user to get a public IP address (for example, a public IP address for a local NAT150or ICI160), connect to other devices (for example, remote ICIs160), disconnect from other devices (for example, remote ICIs160), add or delete other devices (for example, remote ICIs160) to its own database, and/or perform other tasks.

FIG. 8depicts an address retrieval process800according to an embodiment of the invention. For example, a user may click the “Get Public IP Address” button on the GUI600ofFIG. 7. This may cause the ICI device to attempt to retrieve its own public IP address from a source such as a public server for identifying IP addresses. In other cases, the ICI device may attempt to retrieve its own IP address automatically or due to some other prompt. In some cases, a user may manually enter an IP address. Obtaining a public IP address may allow an ICI device that is on a private network protected by a NAT150to use the public IP address for communication with devices on other networks, because the ICI device itself may only have a private network address that may be unsuitable for communications via the Internet or other open network.

As seen inFIG. 8, when the address retrieval process800begins, the ICI device may contact a public server via the Internet or some other suitable connection810. The public server may return the ICI device's IP address to the device. To ensure the IP address is correct, the ICI device may contact a plurality of public servers810and compare the returned addresses820. If the ICI device receives a plurality of identical IP addresses830, it may save the IP address840that is the identical address. If the ICI device does not receive any matching IP addresses830(because all returned addresses are different or it does not receive a plurality of returned addresses), the ICI device may not enter an IP address automatically. A user may manually enter an IP address850, and in some cases the user may later manually enter an IP address even if a matching plurality of addresses is received. When an IP address is determined, the IP address may be automatically associated with the ICI device in some embodiments, or a user may click an “Update Status” button as shown in the GUI600to associate the IP address with the ICI device. The public IP address may be used by the ICI device to enable device communications with outside devices. For communications between the ICI device and other devices in the same private network (for example SIP phones or a second ICI device on the same local network120), the private address may be used.

As noted above, a first ICI device and/or user may share this device IP address with a second ICI device and/or a user of a second device. The second ICI device may store information about the first ICI device, which may include the public IP address, and thereby register the first ICI device with itself. Note that when the ICI device is on a private network with private IP addresses, such as a network protected by a NAT150, the public IP address determined by this process may be an address for the NAT150. When the ICI device is not protected by a NAT150or similar security measure, the public IP address may be an actual IP address for the ICI device itself.

FIG. 9depicts a GUI600according to an embodiment of the invention. In this example GUI600, an address of record (AOR) registration interface is shown. An AOR may be a unique identifier for a device and/or a user. An AOR may be used by an ICI device to identify a target for connection. In an ICI device's memory, an AOR for another ICI device may be linked to other data about its associated device, such as the IP address and/or other connection information for the device. Like the IP address, a first ICI device and/or user may share an AOR with a second device and/or user. In this example, a name (for example a device name or user name) and a local network name are used to generate an AOR. For example, the user name “bob” and local network “Biloxi” are used to form the AOR “sip:bob@biloxi”. In this example, the AOR is a combination of a user name, an “@” symbol, and an ICI160name. The ICI160name may be established when the ICI160is installed on a network. For example, the ICI160name may be a name of the network or may be chosen by an administrator or in some other way (i.e. a user Robert Smith may create an AOR and ICI160name for a home network such as Robert@theSmiths). In some embodiments, an ICI Uniform Resource Identifier (URI) may be formed by prefixing the AOR. For example, the AOR may be prefixed with “sip:” (e.g., sip:Robert@the Smiths). If another user wishes to contact Robert Smith, they may enter Robert Smith's URI into their GUI600to initiate a connection. In some embodiments the AORs (and therefore the URIs) may be created locally by a user or administrator as opposed to centrally by a central registration system. In some embodiments, the local network may appear in the AOR for all devices associated with that network. In other examples and embodiments, AORs may have other formats.

FIG. 10depicts a GUI600according to an embodiment of the invention. In this example GUI600, a phone registration interface is shown. One or more phones (or other devices) may be associated with one or more AORs. For example, a device having a local IP address 127.0.0.1 is associated with AOR sip:bob@biloxi. As seen in this example, registration dates, expiration dates (indicating when registration will lapse), and/or device groups may be associated with registered devices. The AOR and/or other identifying data may contain information about the ICI device and the associated SIP device to which communications are to be directed, so that specific SIP devices may be reached when an ICI device is associated with a plurality of SIP devices.

FIG. 11depicts a device registration process1200according to an embodiment of the invention. This process1200may verify the authenticity of an AOR and register devices associated with the AOR to enable secure communications between them and other devices associated with other registered AORs. For example, this process1200may be used to register a SIP phone on one network with an ICI device on the same network, so that the SIP phone may use the ICI device for external communications. A first device may transmit a device registration request to a second device or local ICI160associated with the second device with which it wishes to be registered1210. The second device may extract an AOR from the registration request1220. The second device may search its secure database to determine whether the AOR is stored in the secure database (which may be, for example, an AOR registration database)1230. The AOR may be in the secure database if, for example, it was previously entered into the database by a user of the second device or the ICI160associated with the second device. In some embodiments, AORs may be exchanged between devices over separate secure channels or otherwise received and stored by devices (e.g., via email between users or the like). If the AOR is not registered1240, the request to register the device associated with the AOR may be discarded1250and/or an error message may be delivered to the device. If the AOR is registered1240, the ICI160may get a uniform resource identifier (URI) or other device identifier, IP address, and/or other AOR contact information from the request1260and may store the URI in the secure database and/or link the URI to the associated AOR in the secure database1270. In the event of an incoming call, an ICI160may look up the IP address of the device to which the call is directed in its database using the AOR or other unique identifier and then may use the IP address to send the call to the local device to which the call has been placed.

FIG. 12depicts a connection process900according to an embodiment of the invention. When a first device has information about a second device, the first device may attempt to connect to the second device. For example, the first device may get information about the second device910. This may be done through an exchange of data with the second device through some other channel, by retrieving the information from memory or an outside data source, and/or by an exchange between the device users. The information may include a name of the second ICI device and/or connection information useful to connect to the second device, such as the second device's IP address, port, public key, a device name associated with the ICI device, and/or other data. The first ICI device may create an SSLContext920and create an SSLEngine using the SSLContext930. Unlike the example ofFIG. 5above, the first ICI device may set a “use client mode” flag (or other setting enabling client mode) to true940, because an ICI device functioning as a client may be able to transmit data to another device. Once in client mode, the first ICI device may attempt to connect to the second ICI device950. Aspects of an example connection attempt (and communication process once connected) are described in further detail with respect toFIGS. 34-35below. If the attempt is unsuccessful, the first ICI device may report a connection error960and/or restart the connection process. If the attempt is successful, the first ICI device may save information about the connection and store it in a hash table so that it can be reused for future communications with the same second ICI device970. For example, this saved information may comprise proper dynamic host table routing and/or other information.

FIG. 34depicts a communication process3400according to an embodiment of the invention. This process3400may be used by a first ICI device attempting to connect and/or communicate with a second device using an ICI protocol170. The process3400may enable connecting devices to negotiate optimal parameters for connection in the SDP. This process3400may comprise swapping a public and private IP address for a device, which may enable ICI protocol170communications between that ICI device and other ICI devices such that the communications may be capable of traversing a NAT150or other security measure.

A first ICI device may build an IP packet3410for sending to a second ICI device associated with another local network. The first ICI device may check whether its IP address and the public IP address for the first ICI device's NAT150(determined, for example, by the first ICI device according to the process800ofFIG. 8and stored in the first device's secure database) are the same3420. If they are not, for example when the first ICI device is on a private network, the first ICI device may replace the IP address in the packet with the stored NAT150IP address3430. If the first ICI device is behind a NAT150, the private IP address of the first ICI device can't be used by the remote SIP phone device. In that case, the first ICI device may replace its private IP address in the SDP with the public IP address of the NAT150. This public IP address may allow the remote SIP phone device to communicate with the SIP phone device in the private address space by means of the NAT150, via the first and second ICI devices. Then the first device may send the IP packet3440. If the IP address for the first ICI device and the public IP address (determined, for example, by the first ICI device according to the process800ofFIG. 8and stored in the first device's secure database) are the same, the swapping process of the first device may default to using the existing IP address in the packet and send the negotiation exchanges from the first SIP device to a remote ICI device for communication directly to the second SIP device3440.

FIG. 35depicts a connection process3500according to an embodiment of the invention. In this example process3500, communication between a SIP device (not shown) on the Atlanta network120and a SIP device (not shown) on the Biloxi network120is being initiated by the ICI160associated with the Atlanta network120. In this example, the ICIs160of both networks120are configured to listen to port5061of their associated NATs150(in server mode, as described above), but it will be understood that other ports may be used.

The process3500may be initiated when an SIP device on the Atlanta network120may attempt to call a SIP device on the Biloxi network120. The process3500may also be initiated to open a channel between the Atlanta and Biloxi networks120that may be used for future calls between SIP devices. The Atlanta ICI160may attempt to connect3505to the Biloxi NAT150through port5061of the Biloxi NAT150(in client mode, as described above). The Atlanta ICI160may generate a TCP sync message3510and the Atlanta NAT150may open port5061(the NAT150may be directed to open this port by the ICI160)3515. The TCP sync message may be transmitted via ICI protocol3520and received by the Biloxi NAT150. The Biloxi NAT150may reject the sync command because it has no open port3525. The Atlanta ICI160may report a timeout3530because the sync command was rejected by the Biloxi NAT150. The Biloxi ICI160, which is listening to the Biloxi NAT150port5061(in server mode, as described above), may detect the traffic from the Atlanta ICI160and attempt to connect3535to the Atlanta NAT150through port5061of the Atlanta NAT150(in client mode, as described above). In some embodiments, the connection process of the Biloxi ICI160may be manually initiated by a user clicking a connect button instead of via an automated process. The Biloxi ICI160may generate a TCP sync message3540. The TCP sync message may be transmitted via ICI protocol3545and received by the Atlanta NAT150. The sync message from the Biloxi ICI160may go through the Atlanta NAT150at port5061because the port has been opened3550. The Atlanta ICI160may receive the sync message and transmit a sync and acknowledgement3555via ICI protocol3560to the Biloxi ICI160, which may receive the data3565. The Biloxi ICI160may send an acknowledgement3570to the Atlanta ICI, and communications between the ICIs160may now be open via port5061on the Atlanta NAT150and the Biloxi NAT150.

With an ICI protocol channel open and the NAT150security traversed, the Atlanta ICI160and the Biloxi ICI160may perform an SSL handshake3575and communicate with one another. For example, SSLContexts and/or SSLEngines such as those described in the context ofFIG. 5above may be used by the ICIs160. The communications between ICI160devices may use private network addresses to direct the communications to the appropriate SIP devices within the local networks120once the channel has been opened. An incoming request to open a connection from a remote ICI160may cause a local ICI160to perform certification validation and SSL handshake procedures. If an SSL handshake is successful, the SSLEngines of the ICIs160may negotiate a secret key. The secret key may be used by each ICI160to encrypt information provided by a SIP device before the ICI160sends the information to the remote ICI160. Note that both ICIs160are in server mode when listening for and/or receiving data and are in client mode when sending data throughout the entire process3500ofFIG. 35.

FIGS. 13-32depict various networks to illustrate example network and/or device configurations. Those of ordinary skill in the relevant art will appreciate that these examples are not exhaustive.FIG. 13depicts a network1300according to an embodiment of the invention. This network1300has an overall configuration similar to that of the network100inFIG. 1. In the network1300, SIP devices may use a variety of different protocol versions. For example, devices associated with either the Atlanta or Biloxi networks120may have IPv4 private addresses within the network120while the NATs150use IPv4 public addresses to communicate with other computers via the Internet110. Devices associated with either the Atlanta or Biloxi networks120may have IPv4 public addresses within the network120while the NATs150use IPv4 public addresses to communicate with other computers via the Internet110. Devices associated with either the Atlanta or Biloxi networks120may have IPv4 addresses (private or public) within the network120while the NATs150use IPv6 addresses to communicate with other computers via the Internet110. Devices associated with either the Atlanta or Biloxi networks120may have IPv6 addresses within the network120while the NATs150use IPv6 addresses to communicate with other computers via the Internet110. Other protocols and protocol combinations may be used in various embodiments.

FIG. 14depicts a network1400according to an embodiment of the invention. This network1400has an overall configuration similar to that of the network100inFIG. 1, but wherein each local network120has a plurality of associated communication devices such as SIP softphones130and SIP hardphones140. Also, in this embodiment all connections between various devices (SIP softphones130, SIP hardphones140, and ICI160) and the local networks120are wired connections180.

FIG. 15depicts a network1500according to an embodiment of the invention. This network1500has an overall configuration similar to that of the network1400inFIG. 14, but in this embodiment connections between various devices (SIP softphones130, SIP hardphones140, and ICI160) and the local networks120may be either wired connections180or wireless connections190. For example, all devices (SIP softphones130, SIP hardphones140, and ICI160) associated with the Atlanta network120have wired connections180, and all devices (SIP softphones130, SIP hardphones140, and ICI160) associated with the Biloxi network120have wireless connections190.

FIG. 16depicts a network1600according to an embodiment of the invention. This network1600has an overall configuration similar to that of the network1500inFIG. 15, but in this embodiment the local networks are enterprise networks121such as university or corporate networks, for example. The separate enterprise networks121may be unrelated enterprise networks121(for inter-domain communications) or may be separate portions of the same enterprise network121(for intra-domain communications).

FIG. 17depicts a network1700according to an embodiment of the invention. This network1700has an overall configuration similar to that of the network1500inFIG. 15, but in this embodiment one of the local networks is an enterprise network121and one of the local networks is a residential network122such as a network provided by a home wireless router, for example. This situation may arise when a user of a residential network122is working or studying from home and wishes to access their corporate or university network, for example.

FIG. 18depicts a network1800according to an embodiment of the invention. This network1800has an overall configuration similar to that of the network1500inFIG. 15, but in this embodiment the local networks are residential networks122. This situation may arise when users of devices associated with separate residential networks122wish to communicate with one another using social media, chat, or voice software, for example. In some embodiments, this scenario may correspond to users of separate devices associated with a social network at least partly based on communications made via an ICI protocol170.

FIG. 19depicts a network1900according to an embodiment of the invention. This network1900has an overall configuration similar to that of the network1500inFIG. 15, but in this embodiment one of the local networks is a residential network122and another local network is a hotel network123. This demonstrates a situation wherein a user who is traveling wishes to communicate with devices associated with a home network122. For example, the residential network122may have an answering machine131and/or a security camera142capable of communicating via an ICI protocol170. A user may use a device such as a video phone132and/or mobile phone143with the hotel network123to view camera142footage or check messages recorded by the answering machine131.

FIG. 20depicts a network2000according to an embodiment of the invention. This network200has an overall configuration similar to that of the network1500inFIG. 15, but in this embodiment one of the local networks is a residential network122and another local network is a multimedia service network124. A multimedia service network124may be any kind of network providing multimedia content and/or access to external services. For example, the multimedia service network124in this network2000is associated with a SIP gateway144. A SIP gateway144may be a computer that is capable of linking non-ICI compatible computers with an ICI160for communication via an ICI protocol170. In this example network2000, the SIP gateway144provides a connection to a public switched telephone network PTSN2010. PTSN legacy phones2020and/or other PTSN2010compatible devices may communicate with other devices through the SIP gateway144. For example, a SIP softphone130and/or SIP hardphone140associated with the residential network122may be able to call and/or receive calls from a legacy phone2020by communicating via ICI160with the SIP gateway144.

FIG. 21depicts a network2200according to an embodiment of the invention. In this example network2200, a single local network120and public network110are shown, but those of ordinary skill in the relevant art will appreciate that additional networks may be combined with these networks in other embodiments. This network2200is an example of a network2200wherein all connections between devices on the local network120(such as the SIP softphone130, SIP hardphone140, and ICI160) are wired connections180.

FIG. 22depicts a network2300according to an embodiment of the invention. This example network2300has an overall configuration similar to that of the network2200ofFIG. 21, but in this embodiment all connections between devices on the local network120(such as the SIP softphone130, SIP hardphone140, and ICI160) are wireless connections190.

FIG. 23depicts a network2400according to an embodiment of the invention. This example network2300has an overall configuration similar to that of the network2200ofFIG. 21, but in this embodiment some connections associated with the local network120are wired connections180, and some connections associated with the local network120are wireless connections190. For example, in this specific embodiment an ICI160and an SIP softphone130have wireless connections190to the network, and an SIP hardphone140has a wired connection180to the network.

FIG. 24depicts a network2500according to an embodiment of the invention. This example network2500has an overall configuration similar to that of the network2300ofFIG. 22. This network2500demonstrates an example wherein the local network is a private network125and the publicly accessible network is also a private network111of some type. For example, a password-protected private portion of the Internet or a private large scale corporate network may be associated with one or more local private networks125. Devices130,140on the local private networks125may communicate with one another using ICI160and the private network111.

FIG. 25depicts a network2600according to an embodiment of the invention. This example network2600has an overall configuration similar to that of the network2300ofFIG. 22. This network2600demonstrates an example wherein the local network is a private network125and the publicly accessible network is a broadly accessible public network such as the Internet110.

FIG. 26depicts a network2700according to an embodiment of the invention. This example network2700has an overall configuration similar to that of the network2300ofFIG. 22, except that there is no NAT150between the local network and the public Internet110. The local network in this example may be a public network126(such as a WiFi hotspot) or a network using security measures other than those provided by a NAT150. Without the presence of a NAT150between a public network126and the public Internet110, a device130,140may have the same IP address within the local public network126and the public Internet110. Even so, the ICI160may be used by such a device130,140to communicate with other devices. Software associated with an ICI160may determine that swapping a public and private address as described in the connection processes above may be unnecessary for a device130,140on a public network126, and the ICI160may omit swapping for that device130,140.

FIG. 27depicts a network2800according to an embodiment of the invention. This example network2800has an overall configuration similar to that of the network2300ofFIG. 22, but the local network120is associated with a combination device2810comprising a SIP softphone130and ICI160in a single unit. A combination device2810may enable a user to communicate via ICI protocol170while connected to local networks120that do not have dedicated ICI160devices. In some embodiments, such a combination device2810may also allow other devices130,140associated with the same local network120to communicate via ICI protocol170with devices on other networks using the combination device's2810ICI160.

FIG. 28depicts a network2900according to an embodiment of the invention. In this network2900, three local networks120(Atlanta, Biloxi, and Chicago) are shown and associated with the same larger Internet network110. Each local network120in this example may have its own NAT150and ICI160. In this example, devices on the Biloxi network120may communicate via ICI protocol170with devices on the Atlanta network120and/or the Chicago network120, but devices on the Atlanta network120and devices on the Chicago network120may be unable to communicate with one another via ICI protocol170. This may be because AORs of devices on the Atlanta network120and devices on the Chicago network120are unknown to one another, because of some security or other settings within ICI160software, or for some other reason. In some cases, any of the devices on any of the local networks120may be capable of connecting to one another, and this example may be illustrating an actual device on the Biloxi network120that is communicating with devices on the Atlanta network120and devices on the Chicago network120, for example in a broadcast type communication. The Atlanta and Chicago devices may be able to communicate with the Biloxi device but not with one another. In one example, a connection between Biloxi and Chicago can be established when the Biloxi ICI160is already connected to Atlanta. Any number of concurrent connections may be possible for an ICI160.

FIG. 29depicts a network3000according to an embodiment of the invention. This network3000has a similar overall configuration to the network2900ofFIG. 28, but with a fourth local network120(Denver) having its own NAT150and ICI160added. In this example, devices on the Biloxi network120may communicate via ICI protocol170with devices on the Atlanta network120, the Chicago network120, and/or the Denver network120, but devices on the Atlanta network120, devices on the Chicago network120, and devices on the Denver network120may be unable to communicate with one another via ICI protocol170. In some cases, any of the devices on any of the local networks120may be capable of connecting to one another, and this example may be illustrating an actual device on the Biloxi network120that is communicating with devices on the Atlanta network120, devices on the Chicago network120, and devices on the Denver network120, for example in a broadcast type communication. The Atlanta, Chicago, and Denver devices may be able to communicate with the Biloxi device but not with one another.

FIG. 30depicts a network3100according to an embodiment of the invention. This network3100has a similar overall configuration to the network3000ofFIG. 29, but in this case the local network120ICIs160may be configured such that two separate, unrelated ICI protocol170channels may be available and/or active. In this example, devices on the Atlanta network120and devices on the Biloxi network120may be able to communicate with one another, and devices on the Chicago network120and devices on the Denver network120may be able to communicate with one another (i.e. a point to point configuration). However, communication between Atlanta and/or Biloxi devices and Chicago and/or Denver devices may be impossible or inactive.

FIG. 31depicts a network3200according to an embodiment of the invention. This network3200has a similar overall configuration to the network3100ofFIG. 30, but in this case Atlanta devices may communicate with Chicago devices and Biloxi devices may communicate with Denver devices. However, there is no available and/or active ICI protocol170communication between the Biloxi network120and the Chicago network120or between the Atlanta network120and the Denver network120.

FIG. 32depicts a network3300according to an embodiment of the invention. This network3300has a similar overall configuration to the network3100ofFIG. 30, but in this case devices on any local network120may communicate with devices on any other local network120(i.e. a fully meshed configuration). In this example, each ICI160has access to every other ICI160, so any SIP device on any local network120may connect to any other SIP device on any local network120. In such an embodiment, or any embodiment with an ICI160having multiple active connections, SIP device location lookup processes may be performed through dynamic hash table lookups of linked ICIs160in the meshed network.

FIG. 33depicts a network2100according to an embodiment of the invention. This network2100example includes a public Internet110and two private networks120(Atlanta and Biloxi). Each private network120has a communication device120,140, a NAT150, and an ICI160.FIG. 33also illustrates sample protocol stacks for this embodiment. For example, the stack2110between a device130,140and a local network120may comprise an SIP protocol layer, an IP layer, and a network access data link layer such as a wired or wireless connection. This protocol stack2110may be used for communications between the SIP devices130,140and the ICI device160. Data transmitted between a device130,140and a local network120may also be transmitted between the local network120and an ICI160. A stack2120between the local network120and ICI160may comprise an SIP protocol layer, an IP layer, and a network access data link layer such as a wired or wireless connection. The stack2120between the local network120and ICI160may also comprise transport layer security (TLS) or some other cryptographic protocol in the transport layer and an ICI protocol170enabling the ICI communications discussed above. The TLS or other cryptographic protocol may provide security for ICI communications sent through the Internet110or other public network. This protocol stack2120may be used for communications between ICIs160.