Nuevas características incluidas en una actualización acumulativa para Office Communications Server 2007 R2, Unified Communications administradas API 2.0 Core Redistributable versión de 64 bits de paquete


Resumen


Una actualización a la versión de 64 bits de paquete Unified Communications Managed API 2.0 (UCMA 2.0) Core Redistributable incluye las siguientes características:
  • Soporte para instalar a un cliente en un sistema operativo de 64 bits de Windows Vista Service Pack 1 (SP1) o en un sistema operativo de 64 bits de Windows 7.
  • Interoperabilidad con puertas de enlace de IP PBXs y SIP conmutada red telefónica pública (PSTN) de terceros de voz para Microsoft Office Communications Server 2007 R2.

Más información



Para agregar estas nuevas características, puede descargar la actualización acumulativa para Office Communications Server 2007 R2, Unified Communications Managed API 2.0 (UCMA 2.0) Core Redistributable versión de 64 bits de paquete con fecha de abril de 2010.
Para obtener más información, haga clic en el siguiente número de artículo para verlo en Microsoft Knowledge Base:

976657 descripción de la actualización acumulativa para Office Communications Server 2007 R2, Unified Communications Managed API 2.0 Core Redist 64 bits: abril de 2010




Utilice UCMA 2.0 Core SDK con un paquete de actualización de Microsoft Unified Communications administradas API Redistributable (UcmaRedist.msi). El número de versión de este paquete debe ser mayor que la versión 3.5.6907.170. Este paquete difiere de las versiones anteriores de la base de UCMA 2.0 SDK en la siguiente función.
  • Soporte para la implementación de aplicaciones de UCMA 2.0 Core de 64 bits en la edición de 64 bits de Windows Vista SP1 y en ediciones posteriores, o en la edición de 64 bits de Microsoft Windows 7 64-bit.
  • Introducción de la API de enrutamiento predeterminado, ApplicationEndpoint:
    • El extremo de enrutamiento predeterminado permite que una aplicación procesar las solicitudes SIP entrantes que se reciben en una instancia de CollaborationPlatform. Estas solicitudes no se envían rápidamente a otro ApplicationEndpoint en el mismo CollaborationPlatform. La velocidad a la que se envían las solicitudes depende de si el propietario de ApplicationEndpoint o la información de conversación coincide con la solicitud entrante. En lugar de ser rechazado automáticamente por el CollaborationPlatform, dicha solicitud recibida se produce en la predeterminada enrutamiento ApplicationEndpoint cuando existe. A continuación, una aplicación es capaz de procesar estas solicitudes.
    • Puede haber un máximo de un ApplicationEndpoint marcado como el extremo de enrutamiento predeterminado para una instancia dada de CollaborationPlatform.
    • La llamada se enruta a un servicio dado de baja. Sin embargo, la aplicación no cuelga la llamada. En su lugar, la aplicación reproduce un anuncio al llamador. Cuando el extremo de enrutamiento predeterminado se utiliza como el único ApplicationEndpoint para la plataforma, es ideal para crear servicios que también interactúan con colegas SIP remotos este extremo. El siguiente es un ejemplo de código:
      public class ApplicationEndpoint : LocalEndpoint 
      {
      public Boolean IsDefaultRoutingEndpoint { get; }
      public void SetProxyInformation(String proxyHost, Int32 proxyPort);
      }

      public class ApplicationEndpointSettings : LocalEndpointSettings
      {
      public Boolean IsDefaultRoutingEndpoint { get; set; }
      }
  • Introducción a la compatibilidad con equilibrio de carga de DNS de SIP:
    • UCMA 2.0 Core SDK es capaz de utilizando registros de DNS A las solicitudes SIP salientes a un proxy del próximo salto con varios clientes de equilibrio de carga.
    • Este hotfix no es compatible con DNS equilibrio de carga para failover de comprobación de conectividad de HIELO. Un servidor perimetral de Audio/vídeo de Microsoft Communications Server debe estar representado por un equilibrador de carga de hardware. Éste es un ejemplo de código:
      public abstract class RealTimeConnectionManager : IDisposable 
      {
      public Boolean DnsLoadBalancingDisabled { get; set; }
      }

      Nota: De una implementación LocalEndpoint, puede acceder a él mediante el código siguiente:
      endpoint.InnerEndpoint.ConnectionManager.DnsLoadBalancingDisabled = false;
  • Introducción de un modo de interoperabilidad de plataforma con IP-PBX y puertas de enlace de RTC SIP para escenarios de telefonía compatible con Microsoft Exchange Server 2010.
    • UCMA 2.0 Core SDK proporciona API de primera clase para reemplazar al proxy de salto siguiente extremo en forma de establecimiento AudioVideoCall. Esto permite que una aplicación funcione en modo de SIP Peer-To-Peer con varios SIP puertas de enlace PSTN y PBX IP de forma simultánea. Este hotfix incluye una nueva API de ConnectionContext que se pueden aplicar a las solicitudes salientes de SIP. El siguiente es un ejemplo de código:
          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 también proporciona una API que puede utilizar para autorizar o rechazar las conexiones entrantes, para recuperar los datos de configuración de un interlocutor SIP de remoto específico, manualmente o proporcionar esta información en la propiedad asociada de RealTimeConnection.ApplicationContext antes de la recepción de AudioVideoCall se produce a la aplicación. Éste es un ejemplo de código para la nueva 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; }
      }
    • Un servidor CollaborationPlatform TCP está configurado para permitir la interoperabilidad de voz con remoto interlocutores SIP e IP-PBX. Office Communications Server 2007 R2 no admite servicios de confianza utilizando TCP.
    • Un servidor CollaborationPlatform MTLS está configurado para permitir la interoperabilidad con servidores proxy de Office Communications Server 2007 R2 y extremos. Para la interoperabilidad con remotos interlocutores SIP de otros tipos, como IP-PBX o SIP puertas de enlace de RTC, la nueva clase TrustedDomain habilita una aplicación especificar arbitrarios interlocutores SIP remotos. Para obtener más información, consulte la matriz de interlocutores SIP remoto que es compatible con Microsoft Exchange Server 2010. Éste es un ejemplo de código para la nueva 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
      }
    • Detalles sobre el modo de interoperabilidad con los colegas SIP remotos distinto de Microsoft Office Communications Server 2007 R2 son los siguientes:

      • Compatibilidad con HIELO borrador v6.0 y borrador v19.0 está deshabilitada.
      • Se filtran todos los encabezados "ms-" Además de "ms-diagnóstico" sin un mensaje.
      • Calidad de las mediciones de la experiencia (QoE) no se publican los interlocutores SIP remoto. En su lugar, las métricas se generan constantemente a la aplicación cuando esté disponible.
      • Se ha agregado compatibilidad con menos de SDP INVITE e INVITE. Proporciona interoperabilidad con controladores de terceros llamada.
  • Soporte de desvío como sigue:
    • Este hotfix ofrece a los autores de la aplicación encontrar el desvío de la primero o la último que se produjo antes de recibir una llamada entrante.
    • CallReceivedEventArgs se deriva de InviteReceivedEventArgs. Por lo tanto, expondrá la misma API. Éste es un ejemplo de código:
      public abstract class InviteReceivedEventArgs : SipRequestReceivedEventArgs 
      {
      public DiversionContext DiversionContext { get; }
      }
  • Los diagnósticos de errores de instalación mejorada llamada y calidad como sigue:

    • Métricas de calidad se producen a la aplicación tras terminar un AudioVideoCall en el que se ha establecido correctamente una AudioVideoFlow. Para obtener más información acerca de las métricas de calidad de la experiencia, visite el siguiente sitio Web de Microsoft:http://msdn.microsoft.com/en-us/library/dd905463.aspx
    • Un desarrollador de software puede supervisar si se ha establecido correctamente una sesión de medio al término de una AudioVideoCall establecida. Para las sesiones de medio fallaron, el desarrollador puede consultar información de diagnóstico pertinente para el error de sesión multimedia. Esta información ayuda con el registro y solucionar problemas de conectividad con usuarios remotos. Aquí es un código de ejemplo:
      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; }
      }
  • Este hotfix ofrece soporte para velocidad de muestreo cada dirección de la secuencia. Esta característica permite que las aplicaciones tener un mayor control de la velocidad de muestreo cada dirección de flujo (envío/recepción) en que se pueden utilizar diferentes frecuencias de muestreo. Éste es un ejemplo de código:
    AudioSamplingRate AudioChannelTemplate.ReceiveDirectionSamplingRate (get/set)
    AudioSamplingRate AudioChannelTemplate.SendDirectionSamplingRate (get/set)

    AudioSamplingRate AudioChannel.SendDirectionSamplingRate (get)
    AudioSamplingRate AudioChannel.ReceiveDirectionSamplingRate (get)
  • Soporte técnico para la detección de tono de fax en banda (CNG 1100Hz) como sigue:
    • Esta característica permite que las aplicaciones detectar cuando se recibe un tono de fax de un interlocutor remoto. Si una aplicación está suscrito al evento IncomingFaxDetected, se detecta un fax de las maneras siguientes que son compatibles con Microsoft:
      • En banda (evento de tono CNG en el flujo RTP enviado según RFC 2833)
      • Out-of-band (tono CNG se envía a través del evento RTP).
      Éste es un ejemplo de código:
      IncomingFaxDetectedEventArgs : EventArgs
      ToneController.IncomingFaxDetected
  • Soporte técnico para la velocidad de reproducción como sigue:
    1. Esta característica proporciona a las aplicaciones la capacidad para proporcionar la capacidad de los archivos WMA reproducción a distinta velocidad. Esto permite que las aplicaciones desarrollar interfaces que proporcionan a los usuarios más control sobre cómo consumen el contenido donde mensajes de reproducción pueden ser más rápido o más lento dependiendo de la velocidad de reproducción especificado por la aplicación.
    2. La revisión incluye un nuevo API Player.PlaybackSpeed. La velocidad de reproducción puede ser desde la mitad de la velocidad normal de doble superior a velocidad normal.
  • Mejorado grabadora como sigue:
    • Existen varias API nuevas que se presentan en este hotfix. Estas API están en la clase de registrador. Esta clase permite escenarios más complejos desarrollar.
    • Aplicaciones pueden utilizar Recorder.Paused() para pausar la grabación de contenido. Aplicaciones pueden utilizar el Recorder.Start() para reanudar la grabación desde donde se pausó el archivo.
      Nota: Recorder.Start() se inicia al principio del archivo si Recorder.Stop() se llamó antes. La nueva API es Recorder.Paused y RecorderState.Paused.
    • Aplicaciones pueden utilizar VoiceActivityEvent para detectar si el contenido es "Voz" o un "no". Con esta información, las aplicaciones pueden utilizar estos eventos para recortar silencio no deseado en los archivos grabados por el seguimiento de la escala de tiempo de los eventos. La nueva API es la clase de Recorder.VoiceActivityChanged VoiceActivityChangedEventArgs: EventArgs.
    • Los usuarios también pueden admitir el formato de archivo de codificación nueva que ofrece más opciones de aplicaciones como la salida de archivo de la grabadora. Además de los formatos admitidos ya de WMAAudio@16Kps, se admiten los siguientes:
      • WMA48 - WMAudio a 48 kbps
      • PCM16K - PCM @ 16 KHz, 16 bits por muestra
      • PCM8K – PCM @ 8Khz, 16 bits por muestra
    • Aquí está el código de ejemplo para la nueva API:
      WmaFileSink.EncodingFormat {get;set;}
      enum WmaEncodingFormat

Estado


Microsoft ha confirmado que se trata de un problema de los productos de Microsoft que se enumeran en la sección "Aplicable a".