This domain ain’t big enough for the both of us….
In a recent blog (Intra-Domain Co-Existence Federation) we covered the topic of the challenges of supporting more than one unified communications (UC) system inside a single company (or, more specifically, within a single IP domain). In that blog, there was a brief reference to the issue of UC systems assuming that they are ‘authoritative’ for the domain. In this blog, we are going to delve a little deeper into the issues of trying to host two or more UC systems within the same company.
The term ‘authoritative’ suggests exclusive control – in practice it means that every UC session generated by a UC client is going to be routed to the associated UC server according to some scheme determined by the UC vendor. These schemes vary, and are not dictated by the SIP spec (i.e. RFC 3261): the options from which UC designers can choose include: directly configuring the UC client with the server’s IP address; making a request to an internal DNS or corporate directory server (e.g. LDAP) or using DHCP services. As can be seen, vendors’ different implementation choices create opportunities for non-interoperability.
The authoritative routing issue is compounded by the mechanism that the UC Server uses for locating the destination client. Within SIP, the mechanism is a ‘Registrar’ that stores the IP address of all clients currently logged in. Clearly each vendor’s clients will register with their own servers (i.e. Cisco clients will register with CUCM servers and Microsoft clients will register with Lync servers etc.) and will not have visibility of other vendor’s registration list. Within SIP-based systems (XMPP is slightly different, but we will leave that for another day) the address mechanism is a uniform resource identifier (URI) which, like email, takes the form of ‘email@example.com’. However the URI format does not indicate whether Alice is a Cisco user or a Microsoft user, so UC systems are incapable of differentiating between a user that does not exist and a user of another vendor’s system of which it is unaware. Ignoring the fact that UC vendor systems are not interoperable, the unworkable routing and addressing environment created by the assumption of exclusive authority is the reason that multiple UC systems cannot peacefully coexist.
One approach to the domain sharing issue would be to create subdomains, e.g. firstname.lastname@example.org and email@example.com. The UC server is then able to see that the destination domain is not its own and therefore uses DNS to find and forward the message to the ‘other domain’. However, this is onerous for both the user and IT to maintain and is entirely opaque to external federation contacts. Furthermore, for Alice to be able to communicate with Bob, there would have to be an intermediating gateway element between the subdomains. What would be greatly preferable would be a solution that would obviate the need for sub-domains and would intermediate between the UC protocol dialects of different vendor’s UC systems within the domain as well as those of external federation contacts. Such a solution would look a lot like NextPlane.