locked
Interop with OCS RRS feed

  • Question

  • Hi All,
     there is a scenario that I am working on where a set of users are provisioned on to OCS and another set on to some other XMPP based open source IM system. These sets of users are non-intersecting, but work for the same organization, say example.com. Which means that an OCS user doesnt exist on the XMPP system and vice-versa.

    The problem is to get them exchange IM/Presence with each other.

    One way to solve this seemed to be through federation, where the XMPP universe could add unsers from OCS as usrocs@ocs.example.com and OCS users add XMPP users as usrxmpp@xmpp.example.com ( although both exist as usr@example.com in the company ) and use the federation of each system to route it to some server in the middle that replaces the 'from' and 'to' addresses appropriately and injects it into the respective system. For example, if a OCS user sent a message to another XMPP user, we could set up the edge server to route all packets destined for xmpp.example.com to a particular machine where a gateway application runs. This application would replace the 'from address' from @example.com to @xmpp.example.com and the 'to' address from xmpp.example.com to example.com and so on. But this solution as you can see is very messy.

    What I was hoping for is this : say there are 2 users, usrxmpp and usrocs. now, if usrocs wanted to straightway add usrxmpp@example.com, the domain controller wouldn't know about such a user ( usrxmpp)  and it would fail, it would be ideal if it were possible to somehow configure OCS to forward these 'failed' packets somewhere so that such failed users could be looked up in the XMPP set of users. Also some way of solving the reverse too, i.e. if a packet from usrxmpp@example.com to usrocs@example.com were sent to the OCS server, it would suppress error checking and forward the packet.


    Any other ideas / ways of solving this / pointers would be greatly appreciated too.

    Thanks in advance


    Monday, January 19, 2009 11:44 AM

All replies