Les nouvelles fonctionnalités incluses dans une mise à jour cumulative pour Office Communications Server 2007 R2, Unified Communications Managed API 2.0 Core Redistributable package 64 bits

Informations du Support interne Microsoft

N° de bogue : 123858 (Maintenance du contenu)

Informations du Support interne Microsoft

N° de bogue : 212982 (Live Communications Team)

Résumé

Une mise à jour vers la version 64 bits de package redistribuable de Core Unified Communications Managed API 2.0 (2.0 UCMA) comprend les fonctionnalités suivantes :

  • Prise en charge pour installer un client sur un système d’exploitation de 64 bits Windows Vista Service Pack 1 (SP1) ou sur un système d’exploitation de 64 bits Windows 7.

  • Voix de l’interopérabilité avec les passerelles IP PBX et SIP Public téléphone RTPC (réseau commuté) tiers pour Microsoft Office Communications Server 2007 R2.

Plus d'informations


Pour ajouter ces nouvelles fonctionnalités, vous pouvez télécharger la mise à jour cumulative pour Office Communications Server 2007 R2, Unified Communications Managed API 2.0 (UCMA 2.0) Core Redistributable package 64 bits datée d’avril 2010.
Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :

Description de de la mise à jour cumulative pour Office Communications Server 2007 R2, Unified Communications Managed API 2.0 Core Redist 64 bits : avril 2010




Vous utilisez UCMA 2.0 kit avec un package de mise à jour de Microsoft Unified Communications Managed API redistribuable (UcmaRedist.msi). Le numéro de version de ce package doit être supérieur à la version 3.5.6907.170. Ce package est différent des versions antérieures du noyau UCMA 2.0 SDK dans la fonctionnalité suivante.

  • Prend en charge le déploiement d’applications UCMA 2.0 Core 64 bits sur la version 64 bits de Windows Vista SP1 et versions ultérieures, ou l’Édition 64 bits de Microsoft Windows 7 64 bits.

  • Présentation de l’API de routage par défaut, ApplicationEndpoint:

    • Le point de terminaison de routage par défaut permet à une application traiter des requêtes SIP entrantes qui sont reçus par une instance de CollaborationPlatform. Ces demandes ne soient pas expédiés rapidement à un autre ApplicationEndpoint sur le même CollaborationPlatform. La vitesse à laquelle les demandes sont expédiés dépend si le propriétaire de la ApplicationEndpoint ou les informations de conversation correspond à la requête entrante. Au lieu d’est automatiquement rejetée par le CollaborationPlatform, une telle demande reçue est déclenchée sur la valeur par défaut de routage ApplicationEndpoint lorsqu’il en existe un. Ensuite, une application est en mesure de traiter ces demandes.

    • Il peut y avoir un maximum d’un ApplicationEndpoint qui est marqué comme étant le point de terminaison routage par défaut pour une instance donnée de la CollaborationPlatform.

    • Un appel est acheminé vers un service mis hors service. Toutefois, l’application ne se bloque pas l’appel. Au lieu de cela, l’application lit une annonce à l’appelant. Lorsque le point de terminaison de routage par défaut est utilisé comme l’unique ApplicationEndpoint pour la plate-forme, ce point de terminaison est idéal pour créer des services qui interagissent également avec leurs homologues SIP à distance. Voici un exemple de code :

      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 à la prise en charge de l’équilibrage de la charge DNS de SIP :

    • Kit de UCMA 2.0 est capable d’équilibrage des demandes SIP sortants à un proxy de tronçon suivant avec plusieurs ports front-end à l’aide d’enregistrements DNS A.

    • Ce correctif ne gère pas le DNS équilibrage de charge pour le basculement sur incident de glace connectivité à cocher. Un serveur Edge de Microsoft Communications Server Audio/vidéo doivent être fronted par un équilibreur de charge matériel. Voici un exemple de code :

      public abstract class RealTimeConnectionManager : IDisposable 
      {
      public Boolean DnsLoadBalancingDisabled { get; set; }
      }


      Remarque À partir d’une implémentation de LocalEndpoint, vous pouvez l’accéder par le code suivant :

      endpoint.InnerEndpoint.ConnectionManager.DnsLoadBalancingDisabled = false;
  • Introduction d’un mode d’interopérabilité de plate-forme avec les passerelles RTPC de SIP et IP-PBX pour les scénarios de téléphonie pris en charge par Microsoft Exchange Server 2010.

    • UCMA 2.0 kit fournit des API pour ignorer le proxy de tronçon suivant de point de terminaison sur une base d’établissement AudioVideoCall. Cela permet à une application de fonctionner simultanément en mode SIP Peer-To-Peer avec les passerelles RTPC plusieurs SIP et PBX IP. Ce correctif introduit une nouvelle API ConnectionContext qui peuvent être appliqués à des demandes sortantes SIP. Le code suivant est un exemple :

          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; }
      }

    • Kit de UCMA 2.0 fournit également une API que vous pouvez utiliser pour autoriser ou refuser les connexions entrantes, pour récupérer des données de configuration à propos d’un homologue SIP à distance spécifique, manuellement ou pour fournir ces informations dans la propriété RealTimeConnection.ApplicationContext associée avant la réception de AudioVideoCall est déclenché à l’application. Voici un exemple de code pour la nouvelle 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 serveur CollaborationPlatform de TCP est configuré pour permettre les interactions vocales avec à distance les homologues SIP et IP-PBX. Office Communications Server 2007 R2 ne gère pas les services de confiance à l’aide de TCP.

    • Un serveur CollaborationPlatform de MTLS est configuré pour permettre l’interopérabilité avec les serveurs proxy d’Office Communications Server 2007 R2 et les points de terminaison. Pour l’interopérabilité avec des homologues SIP distants d’autres types, tels que IP-PBX ou les passerelles RTPC SIP, la nouvelle classe TrustedDomain permet à une application spécifier des homologues SIP distants arbitraires. Pour plus d’informations, consultez la matrice des homologues distants SIP qui est pris en charge par Microsoft Exchange Server 2010. Voici un exemple de code pour la nouvelle 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
      }
    • Pour plus d’informations sur le mode de l’interopérabilité avec des homologues SIP distants que Microsoft Office Communications Server 2007 R2 sont les suivantes :

      • Prise en charge de glace brouillon v6.0 et brouillon les v19.0 est désactivée.

      • Tous les en-têtes « ms- » outre « ms-diagnostic » sont filtrés par un message.

      • Qualité des métriques d’expérience (QoE) ne sont pas publiées pour les homologues SIP à distance. Au lieu de cela, les mesures sont constamment élevés à l’application lorsqu’elle est disponible.

      • Prise en charge de SDP sans invitation et RÉINVITER a été ajouté. Il fournit une interopérabilité avec les contrôleurs d’appel tiers.

  • Prise en charge de détournement comme suit :

    • Ce correctif permet les rédacteurs d’application rechercher le premier ou le dernier détournement qui s’est produite avant que vous avez reçu un appel entrant.

    • CallReceivedEventArgs est dérivée de InviteReceivedEventArgs. Par conséquent, elle expose la même API. Voici un exemple de code :

      public abstract class InviteReceivedEventArgs : SipRequestReceivedEventArgs 
      {
      public DiversionContext DiversionContext { get; }
      }
  • Diagnostics de défaillance de l’installation appel améliorée et QoE comme suit :

    • QoE métriques sont déclenchés à l’application lors de l’arrêt d’une AudioVideoCall dans laquelle une AudioVideoFlow a été établie. Pour plus d’informations sur les métriques QoE, visitez le site Web de Microsoft à l’adresse suivante :

    • Un développeur de logiciels peut surveiller si une session de média a été établie lors de la résiliation d’un AudioVideoCall établie. Pour les sessions de support qui a échoué, le développeur peut interroger les informations de diagnostic relatives à l’échec de la session multimédia. Ces informations permettent à l’enregistrement et la résolution des problèmes de connectivité avec les utilisateurs distants. Voici un exemple de 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; }
      }
  • Ce correctif prend en charge les taux d’échantillonnage par la direction du flux de données. Cette fonctionnalité permet aux applications d’avoir plus de contrôle de la fréquence d’échantillonnage par la direction de flux de données (envoi/réception) dans laquelle les taux d’échantillonnage différent peuvent être utilisés. Voici un exemple de code :

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

    AudioSamplingRate AudioChannel.SendDirectionSamplingRate (get)
    AudioSamplingRate AudioChannel.ReceiveDirectionSamplingRate (get)
  • Prise en charge de la détection de tonalité intrabande télécopie (CNG 1100Hz) comme suit :

    • Cette fonctionnalité permet aux applications de détecter lorsque la tonalité d’une télécopie est reçue d’un homologue distant. Si une application est abonnée à l’événement IncomingFaxDetected, de détection d’une télécopie de plusieurs façons qui sont pris en charge par Microsoft :

      • (Événement CNG ton dans le flux RTP envoyé en fonction de la RFC 2833) dans la bande

      • Out-of-band (CNG est envoyée via l’événement RTP).

      Voici un exemple de code :

      IncomingFaxDetectedEventArgs : EventArgs
      ToneController.IncomingFaxDetected
  • Prise en charge de la vitesse de lecture comme suit :

    1. Cette fonction donne aux applications la possibilité de donner la possibilité aux fichiers WMA de lecture à une vitesse différente. Cela permet aux applications de développer des interfaces qui donnent aux utilisateurs plus de contrôle sur l’utilisation du contenu où les messages de lecture peuvent être plus rapide ou plus lent en fonction de la vitesse de lecture qui est spécifié par l’application.

    2. Le correctif inclut une nouvelle Player.PlaybackSpeed d’API. La vitesse de lecture est possible à partir de la moitié de la vitesse normale pour deux fois plus rapide que la vitesse normale.

  • Amélioré enregistreur comme suit :

    • Il existe plusieurs nouvelles API qui est introduites dans ce correctif logiciel. Ces API est dans la classe recorder. Cette classe permet de développer des scénarios plus complexes.

    • Applications peuvent utiliser Recorder.Paused() pour suspendre l’enregistrement de contenu. Applications peuvent utiliser le Recorder.Start() pour reprendre l’enregistrement à partir de l’endroit où le fichier a été suspendu.
      Remarque Recorder.Start() démarre au début du fichier, si Recorder.Stop() a été appelée avant. La nouvelle API est Recorder.Paused et RecorderState.Paused.

    • Applications peuvent utiliser VoiceActivityEvent pour détecter si le contenu est « Voix » ou « Pas de voix ». Avec ces informations, les applications peuvent utiliser ces événements pour rogner silence indésirable dans les fichiers enregistrés par le suivi de la chronologie des événements. La nouvelle API est la classe de Recorder.VoiceActivityChanged VoiceActivityChangedEventArgs : EventArgs.

    • Les utilisateurs peuvent prennent également en charge le nouveau format de fichier codage qui donne aux applications plus d’options en tant que la sortie du fichier enregistreur. En plus des formats déjà prises en charge de WMAAudio@16Kps, les éléments suivants sont pris en charge :

      • WMA48 - WMAudio @ 48 Kbits/s

      • PCM16K - PCM @ 16 KHz, 16 bits par échantillon

      • PCM8K – PCM @ 8Khz, 16 bits par échantillon

    • Voici l’exemple de code pour la nouvelle API :

      WmaFileSink.EncodingFormat {get;set;}
      enum WmaEncodingFormat

État

Microsoft a confirmé l'existence de ce problème dans les produits Microsoft répertoriés dans la section « S'applique à ».

Besoin d’aide ?

Développez vos compétences
Découvrez des formations
Accédez aux nouvelles fonctionnalités en avant-première
Rejoindre Microsoft Insider

Ces informations vous ont-elles été utiles ?

Dans quelle mesure êtes-vous satisfait(e) de la qualité de la traduction ?

Qu’est-ce qui a affecté votre expérience ?

Avez-vous d’autres commentaires ? (Facultatif)

Nous vous remercions pour vos commentaires.

×