Neue Funktionen sind in einem kumulativen Update für Office Communications Server 2007 R2 Unified Communications verwaltete API 2.0 Core Redistributable Package 64-Bit-Version enthalten.


Zusammenfassung


Eine Aktualisierung auf Unified Communications verwaltete API 2.0 (UCMA 2.0) Core Redistributable Package 64-Bit-Version umfasst die folgenden Funktionen:
  • Unterstützung für einen Client auf einem Windows Vista Service Pack 1 (SP1) 64-Bit-Betriebssystem oder auf einem Windows 7 64-Bit-Betriebssystem installieren.
  • Voice-Interoperabilität mit Drittanbietern IP PBXs und SIP Public Switched Telephone Netzwerk (PSTN) für Microsoft Office Communications Server 2007 R2.

Weitere Informationen



Um diese neuen Funktionen hinzuzufügen, können Sie das kumulative Update für Office Communications Server 2007 R2 Unified Communications verwaltete API 2.0 (UCMA 2.0) Core Redistributable Package, 64-Bit-Version, die vom April 2010.
Klicken Sie für weitere Informationen auf die folgende Artikelnummer, um den Artikel in der Microsoft Knowledge Base anzuzeigen:

Beschreibung des kumulativen Updates für Office Communications Server 2007 R2 Unified Communications verwaltete API 2.0 Core Redist 64-Bit 976657 : April 2010




UCMA 2.0 Core SDK verwendet mit Microsoft Unified Communications verwaltete API Redistributable Updatepaket (UcmaRedist.msi). Die Versionsnummer für dieses Paket muss höher als 3.5.6907.170 sein. Dieses Paket unterscheidet sich von früheren Versionen der UCMA 2.0 Core SDK in die folgende Funktion.
  • Unterstützung für die Bereitstellung von UCMA 2.0-Core 64-Bit-Programme auf 64-Bit-Edition von Windows Vista SP1 und spätere Versionen oder die 64-Bit-Edition von Windows 7 64-Bit.
  • Einführung der standardmäßige routing-API, ApplicationEndpoint:
    • Der Standardendpunkt routing kann eine Anwendung SIP-Anfragen verarbeiten, die durch eine CollaborationPlatform-Instanz erhalten. Diese Anfragen sind nicht schnell zu anderen ApplicationEndpoint auf derselben CollaborationPlatform verteilt. Die Anfragen verteilt hängt, ob ApplicationEndpoint Besitzer oder die Unterhaltung Informationen die eingehende Anforderung entspricht. Eine empfangene Anforderung ausgelöst statt automatisch abgelehnt durch die CollaborationPlatform auf die ApplicationEndpoint routing, wenn vorhanden. Dann kann eine Anwendung diese Anfragen verarbeiten.
    • Maximal eine ApplicationEndpoint, die als routing Standardendpunkt für eine bestimmte Instanz CollaborationPlatform gekennzeichnet ist.
    • Ein Anruf ist stillgelegt Dienst weitergeleitet. Die Anwendung hängt jedoch nicht den Anruf. Stattdessen gibt die Anwendung eine Ankündigung wieder an dem Aufrufer. Routing Standardendpunkt als eindeutige ApplicationEndpoint für die Plattform verwendet wird, wird dieser Endpunkt ideal zum Erstellen von Diensten, die auch mit entfernten SIP-Peers. Folgendes ist ein Beispiel:
      public class ApplicationEndpoint : LocalEndpoint 
      {
      public Boolean IsDefaultRoutingEndpoint { get; }
      public void SetProxyInformation(String proxyHost, Int32 proxyPort);
      }

      public class ApplicationEndpointSettings : LocalEndpointSettings
      {
      public Boolean IsDefaultRoutingEndpoint { get; set; }
      }
  • Einführung in DNS SIP-Lastenausgleich unterstützt:
    • UCMA 2.0 Core SDK kann Lastenausgleich ausgehende SIP Anfragen zum nächsten Hop Proxy mit mehreren front-Ends mit DNS A-Datensätze.
    • DNS-Lastenausgleich für Eis Konnektivität Kontrollkästchen Failover unterstützt dieser Hotfix nicht. Ein Microsoft Communications Server AV Edge Server müssen von einer Lastenausgleichshardware konfrontiert. Hier ist ein Codebeispiel:
      public abstract class RealTimeConnectionManager : IDisposable 
      {
      public Boolean DnsLoadBalancingDisabled { get; set; }
      }

      Hinweis Aus der Implementierung einer LocalEndpoint zugreifen durch den folgenden Code:
      endpoint.InnerEndpoint.ConnectionManager.DnsLoadBalancingDisabled = false;
  • Einführung einer Plattform Interoperabilitätsmodus SIP-PSTN-Gateways und IP-PBX Telefonie Szenarios von Microsoft Exchange Server 2010 unterstützt.
    • UCMA 2.0 Core SDK bietet erstklassige APIs zum Endpunkt nächsten Hop Proxy zu Betrieb AudioVideoCall überschreiben. Dies ermöglicht eine Anwendung mehrere SIP-PSTN-Gateways und IP-PBX SIP-Peer-To-Peer-Modus gleichzeitig. Dieser Hotfix stellt eine neue ConnectionContext-API auf ausgehende SIP-Anfragen angewendet werden können. Im folgenden finden ein Beispiel:
          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 stellt auch eine API manuell genehmigen oder ablehnen eingehender Konfigurationsdaten zu einem bestimmten SIP-Remotepeer abrufen können, um diese Informationen in der zugeordneten RealTimeConnection.ApplicationContext Eigenschaft vor dem Empfang AudioVideoCall übermitteln der Anwendung ausgelöst. Hier ist ein Codebeispiel für die neue 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; }
      }
    • TCP-CollaborationPlatform-Server sieht Stimme Interoperabilität mit entfernten SIP-Peers und IP-PBX Office Communications Server 2007 R2 unterstützt nicht vertrauenswürdige Dienste über TCP.
    • Ein Server MTLS-CollaborationPlatform ist auf Interoperabilität mit Office Communications Server 2007 R2-Proxys und Endpunkte konfiguriert. Interoperabilität mit SIP Remotepeers anderer Typen SIP-PSTN-Gateways oder IP-PBX-Anlagen kann die neue vertrauenswürdige Domäne Klasse eine Anwendung an beliebigen SIP Remotepeers. Weitere Informationen finden Sie in der Matrix SIP Remotepeers, die von Microsoft Exchange Server 2010 unterstützt. Hier ist ein Codebeispiel für die neue 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 über den Interoperabilität mit entfernten SIP-Peers als Microsoft Office Communications Server 2007 R2 sind wie folgt:

      • Unterstützung für Eis Entwurf V6. 0 und Entwurf v19.0 ist deaktiviert.
      • Alle "ms-" Header neben "ms-Diagnose" werden aus einer Nachricht gefiltert.
      • Qualität der Experience (QoE) Metriken werden remote SIP-Peers nicht veröffentlicht. Stattdessen werden die Metriken ständig für die Anwendung ausgelöst verfügbar ist.
      • Unterstützung für SDP kleiner laden, und Laden Sie wurde hinzugefügt. Sie bietet Interoperabilität mit Drittanbieter-Aufruf.
  • Unterstützung für Umleitung wie folgt:
    • Diesen Hotfix kann Anwendungsentwickler die erste oder letzte Umleitung gefunden, die vor dem Empfang eines eingehenden Anrufs.
    • CallReceivedEventArgs wird von InviteReceivedEventArgs abgeleitet. Daher wird die gleiche API verfügbar. Hier ist ein Codebeispiel:
      public abstract class InviteReceivedEventArgs : SipRequestReceivedEventArgs 
      {
      public DiversionContext DiversionContext { get; }
      }
  • Call Setup-Fehlerdiagnose und QoE wie folgt erweitert:

    • QoE-Metriken sind für die Anwendung am Ende einer AudioVideoCall mit einem AudioVideoFlow hergestellt wurde ausgelöst. Weitere Informationen über die QoE-Metriken finden Sie auf der folgenden Microsoft-Website:http://msdn.microsoft.com/en-us/library/dd905463.aspx
    • Softwareentwickler kann überwachen, ob Media-Sitzung bei Beendigung einer festgelegten AudioVideoCall hergestellt werden. Fehler bei Media-Sitzung, kann Entwickler diagnostischen Informationen zu Sitzung Datenträgerfehler abgefragt werden. Diese Informationen helfen Protokollierung und Problembehandlung bei Verbindungsproblemen mit Remotebenutzern. Hier ist ein Beispiel:
      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; }
      }
  • Dieser Hotfix bietet Unterstützung für Sampling-Rate pro Stream Richtung. Dieses Feature ermöglicht Clientanwendungen die mehr Kontrolle über die Sampling-Rate pro Stream Richtung (senden/empfangen) mit unterschiedlichen Abtastraten verwendet werden können. Hier ist ein Codebeispiel:
    AudioSamplingRate AudioChannelTemplate.ReceiveDirectionSamplingRate (get/set)
    AudioSamplingRate AudioChannelTemplate.SendDirectionSamplingRate (get/set)

    AudioSamplingRate AudioChannel.SendDirectionSamplingRate (get)
    AudioSamplingRate AudioChannel.ReceiveDirectionSamplingRate (get)
  • Unterstützung für in-Band-Fax-Ton-Erkennung (CNG 1100Hz) wie folgt:
    • Dieses Feature ermöglicht Applikationen zu erkennen, wenn ein Faxton von einem Remotepeer empfangen wird. Wenn eine Anwendung das IncomingFaxDetected Ereignis abonniert wird, wird ein Fax auf folgende Weise erkannt, die von Microsoft unterstützt werden:
      • Band (CNG Ton-Ereignis im RTP-Stream nach RFC 2833 gesendet)
      • Out-of-Band (CNG Ton über das RTP-Ereignis gesendet wird).
      Hier ist ein Codebeispiel:
      IncomingFaxDetectedEventArgs : EventArgs
      ToneController.IncomingFaxDetected
  • Unterstützung für Geschwindigkeit wie folgt:
    1. Dadurch kann Programme bieten die Möglichkeit, die Wiedergabe von WMA-Dateien mit einer anderen Geschwindigkeit. Dadurch können Schnittstellen, die Benutzern besser steuern, wie sie die Inhalte konsumieren entwickeln, Wiedergabe Nachrichten schneller oder langsamer, je nach der Geschwindigkeit, die von der Anwendung angegeben werden können.
    2. Das Update enthält eine neue API-Player.PlaybackSpeed. Geschwindigkeit kann Hälfte normale Geschwindigkeit zweimal schneller als normal sein.
  • Aufzeichnung wie folgt erweitert:
    • Es gibt mehrere neue APIs, die in diesem Hotfix eingeführt. Diese APIs werden in der Recorder-Klasse. Diese Klasse ermöglicht komplexere Szenarien zu entwickeln.
    • Clientanwendungen können Recorder.Paused() Inhalt Aufzeichnung anhalten. Die Recorder.Start() können Programme fortsetzen, wo die Datei angehalten wurde.
      Hinweis Recorder.Start() beginnt am Anfang der Datei, wenn vor Recorder.Stop() aufgerufen wurde. Die neue API ist Recorder.Paused und RecorderState.Paused.
    • VoiceActivityEvent können Programme erkennen "Voice" oder "Kein Audio" handelt. Mit diesen Informationen können Applikationen dieser Ereignisse Sie unerwünschte Pausen in die Dateien der aufgezeichneten zuschneiden, Verfolgen der Zeitleiste der Ereignisse. Die neue API ist Recorder.VoiceActivityChanged VoiceActivityChangedEventArgs: EventArgs.
    • Benutzer unterstützen das neue Codierung Dateiformat, der Anwendung mehr Optionen als Ausgabe der Aufzeichnung. Neben den bereits unterstützten Formate von WMAAudio@16Kps wird Folgendes unterstützt:
      • WMA48 - WMAudio bei 48 Kbit/s
      • PCM16K - PCM @ 16 KHz, 16 Bit pro Abtastung
      • PCM8K – PCM @ 8Khz, 16 Bit pro Abtastung
    • Hier ist das Codebeispiel für die neue API:
      WmaFileSink.EncodingFormat {get;set;}
      enum WmaEncodingFormat

Status


Microsoft hat bestätigt, dass es sich um ein Problem bei den Microsoft-Produkten handelt, die im Abschnitt „Eigenschaften“ aufgeführt sind.