Method and system for enforcing proxy use within an enterprise communications system

Abstract

A method and system for enforcing the user of a proxy server within an enterprise communication system. The system includes an enterprise voice application server configured to act as a SIP proxy to client devices, and a private branch exchange configured to act as a SIP registrar. The client devices are configured to evaluate incoming SIP requests to determine whether they were received via the enterprise voice application server and, if not, to respond with a SIP 305 Use Proxy message referencing the enterprise voice application server in a Contact field. The 305 Use Proxy message forces the PBX or other intermediate SIP server to reroute the SIP request and any subsequent SIP requests in the dialog through the enterprise voice application server.

Description

FIELD

The present application relates to managing calls to or from a mobile device and, in particular, managing calls to or from a mobile device associated with an enterprise.

BACKGROUND

Many enterprises are moving towards using VoIP over their LANs and WLANs to interconnect various terminal devices for voice communications. Moreover, external voice communications with remote parties through, for example, the PSTN, may be converted to VoIP communications for routing within the enterprise communication system. A Private Branch exchange (PBX) typically acts as the interface between the PSTN and the internal enterprise communication system. The PBX provides conversion between digital circuit-switched calls and VoIP calls, and assists in routing calls to the correct terminal device. SIP signaling is commonly used to set-up, manage, and tear-down media paths for the VoIP calls.

In many enterprise communication systems, a proxy server may play a significant role in setting-up and managing calls involving terminal devices. One problem that arises in this regard is ensuring that the proxy server is included in any SIP signaling between a terminal device and other SIP entities, like the PBX.

BRIEF DESCRIPTION OF THE DRAWINGS

Reference will now be made, by way of example, to the accompanying drawings which show example embodiments of the present application, and in which:

FIG. 1 shows, in block diagram form, an example system for managing enterprise-related mobile calls;

FIG. 2 shows, in block diagram form, further details of the enterprise communications system;

FIG. 3 shows a process of enforcing proxy use within the enterprise communication system; and

FIG. 4 shows, in flowchart form, an example method for enforcing proxy use within the enterprise communication system

Similar reference numerals may have been used in different figures to denote similar components.

DESCRIPTION OF EXAMPLE EMBODIMENTS

In one aspect, the present application provides a method of enforcing use of an enterprise voice application server as a SIP proxy server for enterprise VoIP communications. The enterprise includes a client device having a first IP address and a client uniform resource identifier (URI), and a Private Branch eXchange (PBX) configured as a SIP registrar having a registration entry binding the client URI to the first IP address. The enterprise voice application server has a proxy URI and a second IP address. The method includes the steps of receiving, at the client device, a SIP request message from the PBX addressed to the client URI, and determining whether the SIP request message was sent via the enterprise voice application server If the SIP request message was not sent via the enterprise voice application server, then generating and sending a SIP 305 Use Proxy response message to the PBX, wherein the SIP 305 Use Proxy response message references the enterprise voice application server in a Contact field, and re-receiving the SIP request message from the PBX routed via the enterprise voice application server.

In another aspect, the present application provides a client device associated with an enterprise, which includes a Private Branch eXchange (PBX) configured as a SIP registrar and an enterprise voice application server having a proxy uniform resource identifier (URI) and a second IP address. The mobile device includes a communications subsystem for engaging in IP-based communications with the enterprise, wherein the client device is configured to be assigned a first IP address and a client URI; a memory; a user interface for outputting information and for receiving user input; a processor for controlling the communications subsystem, the memory, and the user interface; and a communication application executable by the processor and configured to receive a SIP request message from the PBX addressed to the client URI. The SIP registrar includes a registration entry binding the client URI to the first IP address. The communication application is configured to determine whether the SIP request message was sent via the enterprise voice application server. The communication application is configured to generate and send a SIP 305 Use Proxy response message to the PBX if the SIP request message was not sent via the enterprise voice application server, wherein the SIP 305 Use Proxy response message references the enterprise voice application server in a Contact field.

In yet another aspect, the present application provides a computer program product comprising a machine-readable medium having encoded thereon computer-executable instructions for enforcing use of an enterprise voice application server as a SIP proxy server for enterprise VoIP communications. The enterprise includes a client device having a first IP address and a client uniform resource identifier (URI), and a Private Branch eXchange (PBX) configured as a SIP registrar having a registration entry binding the client URI to the first IP address. The enterprise voice application server has a proxy URI and a second IP address. The computer-executable instructions include instructions for receiving, at the client device, a SIP request message from the PBX addressed to the client URI; instructions for determining whether the SIP request message was sent via the enterprise voice application server; and instructions for generating and sending a SIP 305 Use Proxy response message to the PBX if the SIP request message was not sent via the enterprise voice application server, wherein the SIP 305 Use Proxy response message references the enterprise voice application server in a Contact field.

Other aspects of the present application will be apparent to those of ordinary skill in the art from a review of the following detailed description in conjunction with the drawings.

Embodiments of the present application are not limited to any particular operating system, mobile device architecture, server architecture, or computer programming language.

Referring now to the drawings, FIG. 1 shows, in block diagram form, an example enterprise communications system 10. The example system 10 includes an enterprise local area network (LAN) 20, which is connected, through a firewall 22, to a wide area network (WAN) 30, such as the Internet. The system 10 may also connect to a public switched telephone network (PSTN) 40, and a public land mobile network (PLMN) 50, which may also be referred to as a wireless wide area network (WWAN).

The enterprise system 10 may include a number of enterprise-associated mobile devices 100 (only one shown). In many embodiments, the mobile device 100 and the LAN 20 are owned or operated in common by the enterprise. For example, the mobile device 100 may be provided by the enterprise to one of its employees for use in connection with his or her employment.

The mobile device 100 is configured for wireless communication. In particular, the mobile device 100 includes an appropriate radio transceiver and associated software for communicating with the PLMN 50. The mobile device 100 is capable of both wireless voice and data communications via the PLMN 50. In various embodiments, the PLMN 50 and mobile device 100 may be configured to operate in compliance with any one or more of a number of wireless protocols, including GSM, GPRS, CDMA, EDGE, UMTS, EvDO, HSPDA, WiMAX, or a variety of others. It will be appreciated that the mobile device 100 may roam within the PLMN 50 and across PLMNs, in known manner, as the user moves.

The LAN 20 is enterprise-specific and typically includes a number of networked servers, computers, and other devices. For example, the LAN 20 may connect one or more desktop or laptop computers 104 (one shown). The connection may be wired or wireless (WLAN) in some embodiments. The LAN 20 may also connect to one or more desktop telephone sets 106 (one shown).

The LAN 20 includes one or more mail servers, such as mail server 24, for coordinating the transmission, storage, and receipt of electronic messages for client devices operating within the LAN 20. Typical mail servers include the Microsoft Exchange Server™ and the IBM Lotus Domino™ server. Each user within the enterprise typically has at least one user account within the LAN 20. Associated with each user account is message address information, such as an e-mail address. Messages addressed to a user message address are stored on the LAN 20 in the mail server 24. The messages may be retrieved by the user using a messaging application, such as an e-mail client application. The messaging application may be operating on a user's computer 104 connected to the LAN 20 within the enterprise. In some embodiments, the user may be permitted to access stored messages using a remote computer, for example at another location via the WAN 30 using a VPN connection. Using the messaging application, the user may also compose and send messages addressed to others, within or outside the LAN 20. The messaging application causes the mail server 24 to send a composed message to the addressee, often via the WAN 30.

The system 10 further includes a wireless relay 35 that serves to route messages received over the PLMN 50 from the mobile device 100 to the corresponding enterprise LAN 20. The wireless relay 35 also routes messages from the enterprise LAN 20 to the mobile device 100 via the PLMN 50. The wireless relay 35 is shown, in this embodiment, located with the WAN 30.

The LAN 20 also includes an enterprise mobile data server 26. Together with the wireless relay 35, the enterprise mobile data server 26 functions to redirect or relay incoming e-mail messages addressed to a user's e-mail address within the LAN 20 to the user's mobile device 100 and to relay incoming e-mail messages composed and sent via the mobile device 100 out to the intended recipients within the WAN 30 or elsewhere. The enterprise mobile data server 26 and wireless relay 35 together facilitate “push” e-mail service for the mobile device 100 enabling the user to send and receive e-mail messages using the mobile device 100 as though the user were connected to an e-mail client within the LAN 20 using the user's enterprise-related e-mail address, for example on computer 104.

As is typical in many enterprises, the LAN 20 includes a Private Branch exchange (PBX) 28 having a connection with the PSTN 40 for routing incoming and outgoing voice calls for the enterprise. On one side, the PBX 28 is connected to the PSTN 40, for example, via direct inward dialing (DID) trunks. The PBX 28 may use ISDN signaling protocols for establishing and breaking circuit-switched connections through the PSTN 40 and related signaling and communications. On its other side, the PBX 28 connects to the LAN 20 and, through the LAN 20, to telephone terminal devices, such as conventional desk sets 106, softphones operating on computers 104, etc. Within the enterprise, each individual may have an associated extension number or direct dial phone number. Calls outgoing from the PBX 28 to the PSTN 40 or incoming from the PSTN 40 to the PBX 28 are typically digital circuit-switched calls. Within the enterprise, i.e. between the PBX 28 and terminal devices, voice calls are Voice-over-IP (VoIP) calls. The PBX 28 implements the switching to connect legs and provides the conversion between a circuit-switched call and a VoIP call. In many embodiments, the PBX 28 provides a number of additional functions including automated attendant, interactive voice response, call forwarding, voice mail, etc. It may also implement certain usage restrictions on enterprise users, such as blocking international calls or 1-900 calls.

In the present embodiment, Session Initiation Protocol (SIP) is used to set-up, manage, and terminate media sessions for voice calls.

The LAN 20 may also include one or more wireless access points 70. The wireless access points 70 provide wireless local area network (WLAN) connectivity to mobile devices 100 (or WiFi-enabled computers 104 or telephone sets 106) within the enterprise campus. The wireless access points 70 may be configured in accordance with one of the IEEE 802.11 specifications. The mobile device 100 may be equipped with a suitable antenna, RF transceiver, and software for accessing and using the WLAN connectivity of the wireless access point 70, i.e. the mobile device 100 may be “Wi-Fi enabled”. In this manner the mobile device 100 may establish an IP connection with the LAN 20 enabling relatively fast data communication.

To provide for management of voice calls by enterprise related terminal devices, such as the mobile device 100, the desk telephone set 106, or the computer 104, the LAN 20 includes an enterprise voice application server 60. The enterprise voice application server 60 and the PBX 28 together implement the enterprise communications solution to provide VoIP service to the telephone sets 106, softphones on computers 104, and mobile devices 100 of the enterprise.

The enterprise voice application server 60, together with the configuration of the mobile device 100, ensure that voice calls to or from the mobile device 100 are routed through the enterprise facilities. The mobile device 100 includes a communication application 102, which may include a phone application or other voice-based communication application, for placing and/or receiving VoIP calls. The communication application 102 is configured to employ SIP signaling to set-up, manage, and tear down media paths for VoIP calls. In other words, the communication application 102 renders the mobile device 100 a SIP User Agent (UA). In this regard, the communication application 102 is adapted to generate outgoing SIP messages as a SIP User Agent Client (UAC), and to receive and respond to incoming SIP messages as a SIP User Agent Server (UAS).

The other terminal devices of the enterprise, such as the softphone on the computer 104 and the telephone set 106 are also configured to employ SIP signaling to set-up, manage, and tear down media paths for VoIP calls. Each acts as a SIP UA and includes a communication application (not illustrated) similar to the communication application 102 implemented on the mobile device 100.

The enterprise voice application server 60 is show as a distinct server in FIG. 1; however, in one embodiment, the enterprise voice application server 60 and enterprise mobile data server 26 may be implemented on a common server platform. In another embodiment, the functions and operations of the enterprise voice application server 60 may be implemented within the PBX 28. Other possibilities will also be appreciated.

Reference is now made to FIG. 2, which shows, in block diagram form, further details of the enterprise communications system 10.

The enterprise voice application server 60 includes a call processing module 62. The call processing module 62 allows the enterprise voice application server 60 to send and receive call set-up or management messages to and from the mobile device 100 and/or the PBX 28. The call processing module 62 may be configured to send and receive messages via a WLAN connection with the mobile device 100 through the access point 70, if such a connection is available. In some embodiments, in the absence of a WLAN connection, the call processing module 62 may be configured to send and receive data messages via the WAN 30 and PLMN 50, i.e. through the enterprise mobile data server 26 and wireless relay 35.

In particular, the call processing module 62 sends and receives SIP messages. In some embodiments, the call processing module 62 acts as a SIP proxy vis-à-vis the mobile device 100, softphone on the computer 104, and/or telephone set 106. These terminal devices may be configured to recognize the enterprise voice application server 60 as their outbound proxy for SIP communications. In some instances, the call processing module 62 may be configured to cause the enterprise voice application server 60 to act as a back-to-back user agent between the PBX 28 and the terminal devices, such as mobile device 100, etc.

It will be appreciated that the call processing module 62 may be implemented mainly by way of suitably programmed software components executed by one or more processors within the enterprise communications system 80.

The PBX 28 includes a registrar module 29. The registrar module 29 is configured to act as a SIP registrar for the enterprise domain. In other words, the registrar module 29 is adapted to receive SIP REGISTER requests from the terminal devices 100, 104, 106. As those skilled in the art and familiar with SIP will appreciated, the SIP REGISTER request creates a binding between the SIP URI of the requesting device and one or more contact addresses specified in the SIP REGISTER request. The registrar module 29 maintains a list of bindings accessible to proxy servers and redirect servers within its administrative domain. For example, when a user turns on his mobile device 100, one of the startup operations performed by the communication application 102 on the mobile device 100 is to send a SIP REGISTER request to the PBX 28 specifying a current IP address or other contact address at which the user, in particular the mobile device 100, can be reached.

Incoming call requests received at the PBX 28 that result in a SIP INVITE addressed to one of the terminal devices are routed based on the Contact address information stored in the list of bindings maintained by the registrar module 29. For example, a voice call addressed to the URI user@enterprise.com will be routed based on the binding created by the registrar module 29 between the URI user@enterprise.com and the contact address, such as an IP address or a more specific URL, such as user@domain2.enterprise.com. This allows the SIP INVITE request to be sent directly to, for example, the mobile device 100.

In some instances, it may be desirable to route all SIP messaging through an intermediate entity. For example, in the embodiments of the present invention, it is desired to route SIP signaling through the enterprise voice application server 60. The terminal devices, such as the mobile device 100, are configured to use the enterprise voice application server 60 as their outbound proxy. Accordingly, outgoing SIP INVITE messages and the like will be sent by the terminal devices via the enterprise voice application server 60. The devices and the enterprise voice application server 60 may then use certain mechanisms for ensuring that the enterprise voice application server 60 remains a part of further SIP signaling for that dialog. For example, in some instances the Record-Route command may be employed to keep the enterprise voice application server 60 involved in that dialog. The enterprise voice application server 60 inserts the Record-Route header in the SIP INVITE from the terminal device and subsequent SIP messaging in the dialog passes through the enterprise voice application server 60.

An issue arises with incoming SIP INVITE requests addressed to a terminal device, such as the mobile device :100. The registrar module 29 maintains a binding between the SIP URI associated with the mobile device 100 and its contact address. Accordingly, all SIP INVITES are sent directly to the mobile device 100, without passing through the enterprise voice application server 60.

RFC 3327 entitled Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts defines an extension header field, “Path”, for adding a proxy server to the path for any future requests addressed to an address-of-record. The registrar would add the proxy server as part of the path information stored in association with the binding created for the address-of-record as a result of the REGISTER request. However, to employ the Path operation, the PBX 28 and, in particular, the registrar module 29 must recognize and support this operation. Many PBX vendors consider RFC 3327 to be a security vulnerability and do not support the Path extension.

Another option for maintaining the enterprise voice application server 60 within the path of future SIP dialogs is to structure the registration such that the SIP URIs of the terminal devices are bound to the address of the enterprise voice application server 60 instead of their own addresses In other words, when the enterprise voice application server 60 receives a REGISTER request from, for example, the mobile device 100, it would place its own address in the Contact field of the REGISTER request before passing the request on to the routing module 29 of the PBX 28. Therefore the PBX 28 would bind the mobile device 100 user's SIP URI to the IP address of the enterprise voice application server 60 and any incoming SIP INVITEs addressed to the user's SIP URI would be sent to the enterprise voice application server 60.

A problem with this approach is that many PBXs that implement a registration function will, for security reasons, refuse to accept a common contact address for multiple URIs. In other words, more than one SIP URI cannot have the same contact address in the bindings list. This prevents the enterprise voice application server 60 from using its own address as the contact address for all the SIP URIs within the enterprise. In some instances, PBXs may have an exception to this general rule against multiple registrations for terminal devices that are configured to have more than one line; however, this exception typically must be preconfigured and is not necessarily applicable to the example embodiments disclosed herein.

Reference is now made to FIG. 3, which illustrates a process 200 of enforcing proxy use within the enterprise communication system 10. The process 200 is implemented by the PBX 28, the enterprise voice application server 60, and the terminal device, which in this example is the mobile device 100.

In this example, the mobile device 100 has a SIP URI of user@enterprise.com and an IP address of 10.10.100.102, and the enterprise voice application server 60 has an IP address of 10.10.100.101. The PBX 28 IP address is 10.10.100.100.

The process 200 begins with registration of the mobile device 100. The mobile device 100 initiates registration by sending a SIP REGISTER request to the enterprise voice application server 60 in step 202. The SIP REGISTER request includes user@enterprise.com in the “To” field and IP address 10.10.100.102 in the Contact field.

The enterprise voice application server 60 receives the SIP REGISTER request and forwards it to the PBX 28 in step 204. The Contact field remains 10.10.100.102 in the forwarded request.

The PBX 28 accepts the REGISTER request and creates a binding by which SIP URI user@enterprise.com is associated with contact address 10.10.100.102. In step 206, the PBX 28 sends a SIP 200 OK message back to the enterprise voice application server 60. The enterprise voice application server 60 relays the SIP 200 OK message to the mobile device 100 in step 208. This completes the registration portion of the process 200.

Later, in step 210, the PBX 28 originates a call to the mobile device 100 by sending a SIP INVITE to the mobile device 100. In one example, the call to the mobile device 100 may result from the PBX 28 having received an incoming call from a remote party via the PSTN (not shown). In determining where to send the SIP INVITE, the PBX 28 accesses the registrar list of bindings to look up the contact address for SIP URI user@enterprise.com. There, it finds IP address 10.10.100.102 associated with the SIP URI. It will be appreciated that the PBX 28 may have additional associations through which a user's telephone number or extension is associated with the user's SIP URI. As is shown in FIG. 3, the SIP INVITE is sent directly to the mobile device 100 in step 210.

The mobile device 100 receives the SIP INVITE directly from the PBX 28. It assesses whether the SIP INVITE has arrived via the enterprise voice application server 60 and, finding that it did not, the mobile device 100 sends a SIP 305 Use Proxy response message back to the PBX 28 in step 212. The Contact field within the SIP 305 Use Proxy response message specifies the IP address of the enterprise voice application server 60. The PBX 28 acknowledges safe receipt of the SIP 305 Use Proxy response message with an ACK message in step 214.

The SIP 305 Use Proxy response causes the PBX 28 to route any messages intended for the mobile device 100 to the designated proxy, which in this case is the enterprise voice application server 60. The instruction remains in place for the duration of the dialog, meaning any SIP requests or responses relating to the dialog will be routed to the enterprise voice application server 60.

In step 216, the PBX 28 re-sends the SIP INVITE addressed to the mobile device 100; however, this time it sends the SIP INVITE to the enterprise voice application server 60. The enterprise voice application server 60 forwards the SIP INVITE request to the mobile device 100.

All subsequent SIP requests and responses for this dialog pass through the enterprise voice application server 60.

This process 200 allows an enterprise-related terminal device to be configured to force use of the enterprise voice application server 60 as a SIP proxy even where the PBX 28 is configured to prevent use of RFC 3327 or multiple registration bindings to a single IP address.

Although the foregoing example relates to the mobile device 100, it will be appreciated that the same process may be employed with the softphone on the computer 104 (FIG. 2) or with the telephone set 106 (FIG. 2).

Reference is now made to FIG. 4, which shows, in flowchart form, an example method 300 for enforcing proxy use within the enterprise communication system 10. The method 300 illustrates actions from the point-of-view of the terminal device, such as the mobile device 100 (FIG. 2).

In step 302, the terminal device registers. In practice, the terminal device may be preconfigured with the address of its outbound proxy server, i.e. the enterprise voice application server 60 (FIG. 2). In some embodiments, the terminal device may discover its outbound proxy, i.e. the enterprise voice application server 60, in accordance with standard SIP procedures. In either case, the terminal device sends a SIP REGISTER request message to the enterprise voice application server 60, which then forwards the request to the registrar. The registrar responds with a 200 OK message to the enterprise voice application server 60, which then forwards the 200 OK message to the terminal device to complete registration.

In step 304, the terminal device receives a SIP request. The SIP request may, in some instances, be a SIP INVITE, but it is not necessarily an INVITE. In step 306, the terminal device assesses whether the received request arrived via the enterprise voice application server 60. In one embodiment, the terminal device reads the Via fields of the received SIP request header to determine whether the enterprise voice application server 60 was the most recent intermediate proxy traversed by the SIP request. If it was received via the enterprise voice application server 60, then the terminal device proceeds to step 308 to process the request as per usual. If not, then in step 310, the terminal device responds to the SIP request with a SIP 305 Use Proxy response message. The SIP 305 Use Proxy response message specifies the enterprise voice application server 60 in the Contact field of the response header. An ACK message is received in step 312 in reply to the SIP 305 Use Proxy message, and the method 300 returns to step 304.

The sending SIP server, i.e. the PBX 28, reacts to the SIP 305 Use Proxy message by re-sending the SIP request via the enterprise voice application server 60, which means that the re-sent request will satisfy the evaluation performed in step 306 and the method 300 will proceed to step 308 to process the request.

Certain adaptations and modifications of the described embodiments can be made. Therefore, the above discussed embodiments are considered to be illustrative and not restrictive.

Claims

1. A method of enforcing use of an enterprise voice application server as a SIP proxy server for enterprise VoIP communications, wherein the enterprise includes a client device having a first IP address and a client uniform resource identifier (URI), and a Private Branch eXchange (PBX) configured as a SIP registrar having a registration entry binding the client URI to the first IP address, the enterprise voice application server having a proxy URI and a second IP address, the method being performed by the client device and comprising:

receiving, at the client device, a SIP request message directly from the PBX addressed to the client URI for a call made to the client device; and

determining, from the client device, that the SIP request message was not sent via the enterprise voice application server and, upon said determining, then: sending, from the client device, a SIP 305 Use Proxy response message to the PBX, wherein the SIP 305 Use Proxy response message references the enterprise voice application server in a Contact field, and receiving, at the client device, the SIP request message from the PBX routed via the enterprise voice application server, wherein the enterprise voice application server is the SIP proxy server for a remaining SIP dialogue for the call.

2. The method claimed in claim 1, wherein the SIP request message is an INVITE message relating to a call request from a remote party received by the PBX over the public switched telephone network.

3. The method claimed in claim 1, further including sending a SIP REGISTER request to the enterprise voice application server and receiving a SIP 200 OK response message.

4. The method claimed in claim 3, further including forwarding the SIP REGISTER request from the enterprise voice application server to the PBX, and creating the registration entry.

5. The method claimed in claim 1, wherein the PBX is configured to refuse a registration request that results in binding more than one URI to the same Contact address.

6. The method claimed in claim 1, wherein the determining comprises reading a Via header of the SIP request message and determining that an address for the enterprise voice application server is not listed in the Via header.

7. The method claimed in claim 1, wherein the client device comprises one of a mobile device, softphone, and desk telephone set.

8. The method claimed in claim 1, wherein the SIP 305 Use Proxy response message includes the Proxy URI in the Contact field.

9. The method claimed in claim 1, wherein the SIP 305 Use Proxy response message includes the second IP address in the contact field.

10. A client device associated with an enterprise, the enterprise including a Private Branch eXchange (PBX) configured as a SIP registrar and an enterprise voice application server having a proxy uniform resource identifier (URI) and a second IP address, the client device comprising:

a communications subsystem for engaging in IP-based communications with the enterprise, wherein the client device is configured to be assigned a first IP address and a client URI;

a memory;

a user interface for outputting information and for receiving user input;

a processor for controlling the communications subsystem, the memory, and the user interface; and

a communication application executable by the processor and configured to receive a SIP request message directly from the PBX addressed to the client URI for a call made to the client device,

wherein the SIP registrar includes a registration entry binding the client URI to the first IP address,

and wherein the communication application is configured to determine that the SIP request message was not sent via the enterprise voice application server,

and wherein the communication application is configured to, upon said determination, then:

send a SIP 305 Use Proxy response message to the PBX when the SIP request message was not sent via the enterprise voice application server, wherein the SIP 305 Use Proxy response message references the enterprise voice application server in a Contact field,

wherein the enterprise voice application server is the SIP proxy server for a remaining SIP dialogue for the call.

11. The client device claimed in claim 10, wherein the SIP request message is an INVITE message relating to a call request from a remote party received by the PBX over the public switched telephone network.

12. The client device claimed in claim 10, wherein the communication application is configured to read a Via header of the SIP request message and evaluate whether an address for the enterprise voice application server is listed in the Via header to determine whether the SIP request message was sent via the enterprise voice application server.

13. The client device claimed in claim 10, wherein the client device comprises one of a mobile device, softphone, and desk telephone set.

14. The client device claimed in claim 10, wherein the SIP 305 Use Proxy response message includes the Proxy URI in the Contact field.

15. The client device claimed in claim 10, wherein the SIP 305 Use Proxy response message includes the second IP address in the contact field.

16. A non-transitory machine-readable medium having encoded thereon computer-executable instructions for enforcing use of an enterprise voice application server as a SIP proxy server for enterprise VoIP communications, wherein the enterprise includes a client device having a first IP address and a client uniform resource identifier (URI), and a Private Branch eXchange (PBX) configured as a SIP registrar having a registration entry binding the client URI to the first IP address, the enterprise voice application server having a proxy URI and a second IP address, the computer-executable instructions comprising:

instructions for receiving, at the client device, a SIP request message directly from the PBX addressed to the client URI for a call made to the client device;

instructions for determining, from the client device, that the SIP request message was not sent via the enterprise voice application server; and

instructions for, upon said determining, then:

sending, from the client device, a SIP 305 Use Proxy response message to the PBX when the SIP request message was not sent via the enterprise voice application server, wherein the SIP 305 Use Proxy response message references the enterprise voice application server in a Contact field,

wherein the enterprise voice application server is the SIP proxy server for a remaining SIP dialogue for the call.