Historically, enterprise communications offerings from traditional PBX vendors have required proprietary and expensive terminals. With the advent of SIP, the situation has somewhat eased. Still they predominate the cost equation. Given the speculative benefits of UC, reservations expressed by end-users ( http://www.nojitter.com/blog/231500017 ) and the high cost involved in wholesale upgrade, enterprises prefer to test the waters and also rollout the new service incrementally. But thus far, UC service architectures have been “walled gardens”, meaning non-registered users can not participate in UC sessions. This means enterprises have to be careful in selecting the initial group in a rollout plan. The initial group members have to be both enthusiastic about UC and also be naturally communication with the rest of the group. At least during the initial stages, partners and customers may not have UC capabilities. This means a large portion of enterprise communication will not be UC enabled, further impacting the benefits of UC and further questioning the high cost. If partner companies have UC capability, federating two systems is fraught with incompatibilities. The protocols used by the two systems may not be compatible. Even the services may not be compatible. For example, one system may allow for contact specific Presence information while the other one may not. (Yahoo allows for invisible mode setting per contact and most of XMPP-based system do not) In this case it is not clear which Presence information will be shared by the second system.
Since federation is the most substantial issue, it can be simply eliminated if the originator of a session is allowed to directly contact the server of the second party. The high cost of client devices can be eliminated if the required client is no more than a standard browser. To further eliminate protocol incompatibilities, the server of the second party can dynamically download the protocol routine when the first party’s browser contacts it. Finally, we need to question the necessity to push Presence information to all the contacts. Firstly, just reporting the status of the client device (online/offline, idle) does not make sense when the device is always connected. Obviously seldom will a device be offline and it being idle is no indication that the user is not ready for a session. If PSTN phones were to report Presence information, in most cases it will be online and idle. Indeed, it has become routine to ask “Is this a good time?” before starting an IM chat session. So it is preferable to query the Presence information in real-time and that information be specific to the requestor. Of course it is inefficient if every one is constantly pulling the Presence information. To minimize this, the system will allow a contact to subscribe for notification of change in the status.
This application is designed for cloud infrastructure. New servers are added as registrations require. A registered user can be assigned to any server instance without impacting any service component. This is true because each user is autonomous.
![Summary ,[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)