It doesn't look as though today's Microsoft announcement of a new interoperability approach will affect the company's Unified Communications products, specifically Office Communications Server 2007 or Office Communicator. A company spokesperson couldn't give me any more information than, "The announcement impacts the 'high volume' products which include Office, Exchange and SharePoint." By Microsoft product standards, OCS 2007 certainly isn't "high volume" (yet).
It doesn't look as though today's Microsoft announcement of a new interoperability approach will affect the company's Unified Communications products, specifically Office Communications Server 2007 or Office Communicator. A company spokesperson couldn't give me any more information than, "The announcement impacts the 'high volume' products which include Office, Exchange and SharePoint." By Microsoft product standards, OCS 2007 certainly isn't "high volume" (yet).Ironically, Nortel just announced this week that, as Microsoft's leading voice partner, its Communications Server 1000 is the first IP-PBX to achieve native OCS interoperability. Meaning all the others are still to come.
At Microsoft's launch event for OCS last year, company officials provided the following timetable for projected native OCS interoperability:
Given that the Nortel target slipped by several months, it's unclear when the others will be met.
Basically, what "native interoperability" means is that the IP-PBX can connect via SIP to Microsoft's Mediation Server, which is the gateway by which OCS 2007 connects to anything outside the Microsoft world.
In contrast, where you don't have native interoperability, the Microsoft presenters showed the IP-PBX connecting via PRI to a gateway such as Quintum's, with that gateway connecting into the Microsoft Mediation Server.
The Nortel link above gets into still more detail about the advantages of direct interoperability.
Incidentally, in going through my notes from the OCS announcement event, I noticed that there was some discussion in one of the breakout sessions about SIP trunking, a subject about which I posted earlier today. And it bore out my point that there's still a lot of uncertainty about what the term means: The Microsoft representatives, when queried, used the term "SIP trunk" to mean nothing more than a SIP connection from an IP-PBX to OCS. In fact, Microsoft currently doesn't support the scenario that most of us think of when we think of "SIP Trunking," i.e., connecting an enterprise with a service provider network. From Microsoft's white paper, "Integrating Telephony with Office Communications Server 2007":
Another definition of "SIP Trunking" is the use of SIP and RTP to pass telephony traffic from the enterprise to a telephony network provider without traversing PSTN networks. The main benefit of this scenario is that PSTN traffic is often carried over IP within the service provider's network - having been converted from traditional telephony to IP and back to traditional telephony to complete the call. Since telephony operators carry calls over IP it is more economical for them to take a call that originates in SIP and RTP as far as possible to a termination point before converting it to telephony (if at all, in the case of a called party who has also deployed "SIP Trunking"). While this could also be viewed as another form of federation, there are aspects of this scenario that prevented us from including it in the 2007 release, including the recent emergence of standards supporting this scenario and the subsequent lack of support for those standards in many PSTN networks.
Over the next two years, this latter type of "SIP Trunking" will be thoroughly examined by the Microsoft Unified Communications Group. If, as we expect, Service Providers will be able to support this scenario, it will be possible for enterprises to consider this an alternative to direct integration with the PSTN.
Given that the Nortel target slipped by several months, it's unclear when the others will be met.
Basically, what "native interoperability" means is that the IP-PBX can connect via SIP to Microsoft's Mediation Server, which is the gateway by which OCS 2007 connects to anything outside the Microsoft world.
In contrast, where you don't have native interoperability, the Microsoft presenters showed the IP-PBX connecting via PRI to a gateway such as Quintum's, with that gateway connecting into the Microsoft Mediation Server.
The Nortel link above gets into still more detail about the advantages of direct interoperability.
Incidentally, in going through my notes from the OCS announcement event, I noticed that there was some discussion in one of the breakout sessions about SIP trunking, a subject about which I posted earlier today. And it bore out my point that there's still a lot of uncertainty about what the term means: The Microsoft representatives, when queried, used the term "SIP trunk" to mean nothing more than a SIP connection from an IP-PBX to OCS. In fact, Microsoft currently doesn't support the scenario that most of us think of when we think of "SIP Trunking," i.e., connecting an enterprise with a service provider network. From Microsoft's white paper, "Integrating Telephony with Office Communications Server 2007":
Another definition of "SIP Trunking" is the use of SIP and RTP to pass telephony traffic from the enterprise to a telephony network provider without traversing PSTN networks. The main benefit of this scenario is that PSTN traffic is often carried over IP within the service provider's network - having been converted from traditional telephony to IP and back to traditional telephony to complete the call. Since telephony operators carry calls over IP it is more economical for them to take a call that originates in SIP and RTP as far as possible to a termination point before converting it to telephony (if at all, in the case of a called party who has also deployed "SIP Trunking"). While this could also be viewed as another form of federation, there are aspects of this scenario that prevented us from including it in the 2007 release, including the recent emergence of standards supporting this scenario and the subsequent lack of support for those standards in many PSTN networks.
Over the next two years, this latter type of "SIP Trunking" will be thoroughly examined by the Microsoft Unified Communications Group. If, as we expect, Service Providers will be able to support this scenario, it will be possible for enterprises to consider this an alternative to direct integration with the PSTN.
Over the next two years, this latter type of "SIP Trunking" will be thoroughly examined by the Microsoft Unified Communications Group. If, as we expect, Service Providers will be able to support this scenario, it will be possible for enterprises to consider this an alternative to direct integration with the PSTN.
