Article ID: 977547 - Last Review: October 6, 2011 - Revision: 2.0

New features are included in a cumulative update for Office Communications Server 2007 R2, Unified Communications Managed API 2.0 Core Redistributable package 64-bit version

View products that this article applies to.

System TipThis article applies to a different operating system than the one you are using. Article content that may not be relevant to you is disabled.

Expand all | Collapse all

SUMMARY

An update to the Unified Communications Managed API 2.0 (UCMA 2.0) Core Redistributable package 64-bit version includes the following features:

Support to install a client on a Windows Vista Service Pack 1 (SP1) 64-bit operating system or on a Windows 7 64-bit operating system.
Voice interoperability with third-party IP PBXs and SIP Public Switched Telephone Network (PSTN) gateways for Microsoft Office Communications Server 2007 R2.

Back to the top

To add these new features, you can download the cumulative update for Office Communications Server 2007 R2, Unified Communications Managed API 2.0 (UCMA 2.0) Core Redistributable package 64-bit version that is dated April 2010.
For more information, click the following article number to view the article in the Microsoft Knowledge Base:

976657 (http://support.microsoft.com/kb/976657/ ) Description of the cumulative update for Office Communications Server 2007 R2, Unified Communications Managed API 2.0 Core Redist 64-bit: April 2010

You use UCMA 2.0 Core SDK with a Microsoft Unified Communications Managed API Redistributable update package (UcmaRedist.msi). The version number for this package must be greater than version 3.5.6907.170. This package differs from earlier versions of the UCMA 2.0 core SDK in the following feature.

Support for the deployment of UCMA 2.0 Core 64-bit applications on the 64-bit edition of Windows Vista SP1 and on later editions, or on the 64-bit edition of Microsoft Windows 7 64-bit.
Introduction of the default routing API, ApplicationEndpoint:
- The default routing endpoint enables an application to process incoming SIP requests that are received by a CollaborationPlatform instance. These requests are not quickly dispatched to another ApplicationEndpoint on the same CollaborationPlatform. The speed at which the requests are dispatched depends on whether the ApplicationEndpoint owner or the conversation information matches the incoming request. Instead of being automatically declined by the CollaborationPlatform, such a received request is raised on the default routing ApplicationEndpoint when one exists. Then, an application is able to process these requests.
- There can be a maximum of one ApplicationEndpoint that is marked as the default routing endpoint for a given CollaborationPlatform instance.
- A call is routed to a decommissioned service. However, the application does not hang up the call. Instead, the application plays an announcement back to the caller. When the default routing endpoint is used as the unique ApplicationEndpoint for the platform, this endpoint is ideal for creating services that also interact with remote SIP peers. The following is a code sample:
  public class ApplicationEndpoint : LocalEndpoint { public Boolean IsDefaultRoutingEndpoint { get; } public void SetProxyInformation(String proxyHost, Int32 proxyPort); } public class ApplicationEndpointSettings : LocalEndpointSettings { public Boolean IsDefaultRoutingEndpoint { get; set; } }
Introduction to support for SIP DNS load balancing:
- UCMA 2.0 Core SDK is capable of load balancing outbound SIP requests to a next-hop proxy with multiple front ends by using DNS A records.
- This hotfix does not support DNS load balancing for ICE connectivity check failover. A Microsoft Communications Server Audio/Video Edge Server must be fronted by a hardware load balancer. Here is a code sample:
  public abstract class RealTimeConnectionManager : IDisposable { public Boolean DnsLoadBalancingDisabled { get; set; } }
  Note From a LocalEndpoint implementation, you can access it through the following code:
  endpoint.InnerEndpoint.ConnectionManager.DnsLoadBalancingDisabled = false;

Introduction of a platform interoperability mode with SIP PSTN gateways and IP-PBXs for telephony scenarios supported by Microsoft Exchange Server 2010.

UCMA 2.0 Core SDK provides first-class APIs to override the endpoint next-hop proxy on an AudioVideoCall establishment basis. This enables an application to operate in SIP Peer-To-Peer mode with multiple SIP PSTN Gateways and with IP-PBXs simultaneously. This hotfix introduces a new ConnectionContext API that can be applied to outbound SIP Requests. The following is a sample code:

    public class ApplicationEndpointSettings : LocalEndpointSettings 
{
        public ConnectionContext AudioVideoAuthorizationService { get; set; }
}

    public class CallEstablishOptions 
{
        public ConnectionContext ConnectionContext { get; set; }
        public String Transferor { get; set; }
}

public abstract class RealTimeEndpoint 
{
        public IAsyncResult BeginSendMessage(MessageType messageType, RealTimeAddress sessionTarget, SendMessageOptions options, AsyncCallback userCallback, Object state);
}

    public class SendMessageOptions 
{
    public ConnectionContext ConnectionContext { get; set; }    
    public void SetLocalIdentity(String uri, String displayName);
}

public class SignalingSession 
{
        public IAsyncResult BeginEstablish(SignalingSessionEstablishOptions options, AsyncCallback userCallback, Object state);
}

public class SignalingSessionEstablishOptions 
{
        public ConnectionContext ConnectionContext { get; set; } 
}

UCMA 2.0 Core SDK also provides an API that you can use to manually authorize or decline incoming connections, to retrieve configuration data about a specific remote SIP peer, or to deliver this information in the associated RealTimeConnection.ApplicationContext property before the AudioVideoCall reception is raised to the application. Here is a code sample for the new API:

public abstract class RealTimeServerConnectionManager : RealTimeConnectionManager, IDisposable 
{
        public event EventHandler<ConnectionAuthorizationRequestedEventArgs> ConnectionAuthorizationRequested;
}

public class ConnectionAuthorizationRequestedEventArgs : EventArgs 
{
        public ConnectionAuthorizationAction Action { get; }
        public RealTimeConnection Connection { get; }

        public void Allow();
        public void DelayAuthorization();
        public void Deny();
}

public class ConnectionContext 
{
        public ConnectionContext(String host, Int32 port);

        public Int32 Port { get; }
        public String Host { get; }
}

A server TCP CollaborationPlatform is configured to enable voice interoperability with remote SIP peers and IP-PBXs. Office Communications Server 2007 R2 does not support trusted services by using TCP.

A server MTLS CollaborationPlatform is configured to enable interoperability with Office Communications Server 2007 R2 proxies and endpoints. For interoperability with remote SIP peers of other types, such as IP-PBXs or SIP PSTN Gateways, the new TrustedDomain class enables an application to specify arbitrary remote SIP peers. For more information, see the matrix of remote SIP Peers that is supported by Microsoft Exchange Server 2010. Here is a code sample for the new API:

public class CollaborationPlatform 
{
        public Boolean AddTrustedDomain(TrustedDomain trustedDomainEntry);
        public ReadOnlyCollection<TrustedDomain> GetTrustedDomains();
        public Boolean RemoveTrustedDomain(TrustedDomain trustedDomainEntry);

public event EventHandler<ConnectionAuthorizationRequestedEventArgs> ConnectionAuthorizationRequested;
}

   	 	public class ServerPlatformSettings : CollaborationPlatformSettings 
{
        public Collection<TrustedDomain> TrustedDomains { get; }
        public TrustedDomainMode TrustedDomainModeForTcp { get; set; }
}

public class TrustedDomain
{
        public TrustedDomain(String domainName);
        public TrustedDomain(String domainName, TrustedDomainMode domainMode);

        public String DomainName { get; }
        public TrustedDomainMode DomainMode { get; }
}

public enum TrustedDomainMode 
{
        CommunicationsServer,
        Other
}

Details about the interoperability mode with remote SIP peers other than Microsoft Office Communications Server 2007 R2 are as follows:
- Support for ICE draft v6.0 and draft v19.0 is disabled.
- All “ms-” headers besides “ms-diagnostic” are filtered out of a message.
- Quality of Experience (QoE) metrics are not published to the remote SIP peers. Instead, the metrics are consistently raised to the application when it is available.
- Support for SDP-less INVITE and re-INVITE has been added. It provides interoperability with third-party call controllers.

Support for Diversion as follows:
- This hotfix enables application writers to find the first or last diversion that occurred before you received an incoming call.
- CallReceivedEventArgs is derived from InviteReceivedEventArgs. Therefore, it will expose the same API. Here is a code sample:
  public abstract class InviteReceivedEventArgs : SipRequestReceivedEventArgs { public DiversionContext DiversionContext { get; } }

Enhanced call setup failure diagnostics and QoE as follows:

QoE metrics are raised to the application upon terminating an AudioVideoCall in which an AudioVideoFlow was successfully established. For more information about the QoE metrics, visit the following Microsoft Web site:http://msdn.microsoft.com/en-us/library/dd905463.aspx (http://msdn.microsoft.com/en-us/library/dd905463.aspx)

A software developer can monitor whether a media session was successfully established upon termination of an established AudioVideoCall. For media sessions that failed, the developer can query diagnostic information pertinent to the media session failure. This information helps with logging and troubleshooting connectivity issues with remote users. Here is a sample code:

public class AudioVideoCall : Call 
{
        public event EventHandler<MediaTroubleshootingDataReportedEventArgs> MediaTroubleshootingDataReported;
}
public class MediaChannelEstablishmentData 
{
        public MediaChannelEstablishmentStatus EstablishmentStatus { get; }

        public MediaChannelEstablishmentDiagnosticsReason GetDiagnosticsReason();
}

public enum MediaChannelEstablishmentDiagnosticsReason 
{
        Unknown,
        MediaEdgeAuthenticationServiceDiscoveryFailed,
        MediaEdgeAuthenticationServiceCredentialsAcquisitionFailed,
        MediaEdgeResourceAllocationFailed
}

public class MediaTroubleshootingDataReportedEventArgs : EventArgs 
{
        public Collection<MediaChannelEstablishmentData> MediaChannelEstablishmentDataCollection { get; }
        public ContentDescription QualityOfExperienceContent { get; }
}

This hotfix offers support for sampling rate per stream direction. This feature enables applications to have more control of the sampling rate per stream direction (Send/Receive) in which different sampling rates can be used. Here is a code sample:

AudioSamplingRate AudioChannelTemplate.ReceiveDirectionSamplingRate (get/set)
AudioSamplingRate AudioChannelTemplate.SendDirectionSamplingRate (get/set)

AudioSamplingRate AudioChannel.SendDirectionSamplingRate (get)
AudioSamplingRate AudioChannel.ReceiveDirectionSamplingRate (get)

Support for in-band fax tone detection (CNG 1100Hz) as follows:
- This feature enables applications to detect when a fax tone is received from a remote peer. If an application is subscribed to the IncomingFaxDetected event, a fax is detected in the following ways that are supported by Microsoft:
  - In-band (CNG tone event in the RTP stream sent according to RFC 2833)
  - Out-of-band (CNG tone is sent over the RTP event).
  Here is a code sample:
  IncomingFaxDetectedEventArgs : EventArgs ToneController.IncomingFaxDetected
Support for Playback Speed as follows:
1. This feature gives applications the ability to provide the capability to playback WMA files at a different speed. This allows applications to develop interfaces that give users more control over how they consume the content where playback messages can be faster or slower depending on the Playback Speed that is specified by the application.
2. The hotfix includes a new API Player.PlaybackSpeed. Playback Speed can be from half of the normal speed to two-times faster than normal speed.
Enhanced Recorder as follows:
- There are several new APIs that are being introduced in this hotfix. These APIs are in the recorder class. This class makes it possible for more complex scenarios to develop.
- Applications can use Recorder.Paused() to pause the recording of content. Applications can use the Recorder.Start() to resume recording from where the file was paused.
  Note Recorder.Start() starts at the beginning of the file if Recorder.Stop() was called before. The new API is Recorder.Paused and RecorderState.Paused.
- Applications can use VoiceActivityEvent to detect whether the content is “Voice” or “Not Voice”. With this information, applications can use these events to trim unwanted silence in the recorded files by keeping track of the timeline of the events. The new API is Recorder.VoiceActivityChanged class VoiceActivityChangedEventArgs : EventArgs.
- Users can also support the new encoding file format that gives applications more options as the recorder file output. In addition to already supported formats of WMAAudio@16Kps, the following are supported:
  - WMA48 - WMAudio @ 48 kbps
  - PCM16K - PCM @ 16 KHz, 16 bits per sample
  - PCM8K – PCM @ 8Khz, 16 bits per sample
- Here is the code sample for the new API:
  WmaFileSink.EncodingFormat {get;set;} enum WmaEncodingFormat