Нові функції входять до складу накопичувальне оновлення для Office Communications Server 2007 R2 уніфікований зв'язку вдалося API 2.0 основних вторинного розповсюдження пакета 64-розрядної версії


Загальні відомості


Уніфікований зв'язку вдалося API 2.0 (2.0 для інтерфейсу UCMA) ядра вторинного розповсюдження пакета 64-розрядної версії оновлення, містить такі функції:
  • Підтримка для установки клієнта, на 64-розрядної операційної системи Windows Vista з пакетом оновлень 1 (SP1), або на 64-розрядної операційної системи Windows 7.
  • Для Microsoft-Office Communications Server 2007 R2, голосових сумісність з шлюзів IP АТС та SIP спільних перейшли телефону мережі загального користування (ТМЗК) у сторонніх виробників.

Додаткові відомості



Щоб додати ці нові функції, можна завантажити сукупний пакет оновлень для Office Communications Server 2007 R2 Unified зв'язку вдалося API 2.0 (2.0 для інтерфейсу UCMA) ядра вторинного розповсюдження пакета 64-розрядна версія, від квітня 2010 року.
Щоб отримати додаткові відомості, клацніть номер статті в базі знань Microsoft:

Опис 976657 сукупний пакет оновлень для Office Communications Server 2007 R2 Unified зв'язку вдалося API 2.0 основних Redist 64-розрядних: Квітень 2010 року




Основні SDK для інтерфейсу UCMA 2.0 допомогою Microsoft Unified зв'язку вдалося API вторинного розповсюдження пакет оновлень (UcmaRedist.msi). Номер версії для цього пакета, має бути версію 3.5.6907.170. Цей пакет, що відрізняється від попередніх версій основного інтерфейсу UCMA 2.0 SDK в такі функції.
  • Підтримує розгортання інтерфейсу UCMA 2.0 основних 64-розрядних програм у 64-розрядної версії Windows Vista з пакетом оновлень 1 і пізніших версій або до 64-розрядної версії операційної системи Microsoft Windows 7 64-розрядна.
  • За промовчанням маршрутизації API ApplicationEndpointвведення:
    • Кінцева точка за промовчанням маршрутизації, дає змогу застосунку обробка SIP вхідні запити, що надходять з екземпляром CollaborationPlatform. Ці запити не швидко відправлені в іншому ApplicationEndpoint на тому ж CollaborationPlatform. Швидкість, з якою спрямовані на запити залежить від того, чи ApplicationEndpoint власника або розмови інформація відповідає вхідний запит. Замість того, що автоматично скасовуються, у CollaborationPlatform, отриманого запиту, зібрані на значення за промовчанням, маршрутизації, ApplicationEndpoint, якщо він існує. Після цього програма здатний обробляти ці запити.
    • Може бути більше одного ApplicationEndpoint позначено як за промовчанням маршрутизації кінцевої точки даного CollaborationPlatform екземпляра.
    • Виклик надсилається списаних служби. Проте застосунок не завершити виклик. Замість цього застосунку відтворює оголошення для абонента. Кінцева точка маршрутизації за промовчанням використовується як унікальний ApplicationEndpoint платформи, цієї кінцевої точки не підходить для створення служб, які також взаємодіяти з віддаленого SIP-вузлів. Нижче наведено приклад коду:
      public class ApplicationEndpoint : LocalEndpoint 
      {
      public Boolean IsDefaultRoutingEndpoint { get; }
      public void SetProxyInformation(String proxyHost, Int32 proxyPort);
      }

      public class ApplicationEndpointSettings : LocalEndpointSettings
      {
      public Boolean IsDefaultRoutingEndpoint { get; set; }
      }
  • Вступ для підтримки для балансування навантаження в DNS, SIP:
    • Основні SDK для інтерфейсу UCMA 2.0 здатний навантаження вихідних SIP-запити до наступного проксі-сервер із кількох серверах, використовуючи записи на DNS-A.
    • Це виправлення не підтримує навантаження DNS ICE підключення Реєстрація відновлення після відмови. Корпорація Майкрософт Communications Server аудіо/відео межовий сервер має тайським балансування навантаження обладнання. Ось приклад коду:
      public abstract class RealTimeConnectionManager : IDisposable 
      {
      public Boolean DnsLoadBalancingDisabled { get; set; }
      }

      Примітка. Упровадження для LocalEndpoint ви до нього доступ через такий код:
      endpoint.InnerEndpoint.ConnectionManager.DnsLoadBalancingDisabled = false;
  • Введення в режимі сумісності платформи SIP телефонної мережі загального користування шлюзів і IP-АТС для телефонії сценаріїв, які підтримуються в Microsoft Exchange Server 2010.
    • Основні SDK для інтерфейсу UCMA 2.0, забезпечує класу інтерфейси API, щоб змінити кінцевої точки наступного проксі-сервер, на основі створення AudioVideoCall. Це дає змогу, програма для роботи в режимі SIP Peer-To-Peer, кілька шлюзів SIP телефонної мережі загального користування і з IP-АТС одночасно. Це виправлення, представлено новий ConnectionContext API, які можуть бути застосовані до вихідного SIP-запити. Нижче наведено приклад код:
          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; }
      }

    • Ядро SDK для інтерфейсу UCMA 2.0, також надає API, можна дозволити або відхилити вхідних підключень, щоб отримати дані про конфігурацію про певні віддаленого SIP вузол, вручну, або доставити ці відомості, пов'язані RealTimeConnection.ApplicationContext властивості до отримання AudioVideoCall зібрані застосунку. Ось приклад коду для нового 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 налаштовано Увімкнення голосу сумісності з віддаленого SIP вузлів і IP-АТС. Office Communications Server 2007 R2 не підтримує надійних служби за допомогою TCP.
    • MTLS CollaborationPlatform сервер налаштовано на Увімкнення сумісність з Office Communications Server 2007 R2. проксі-сервери та кінцеві точки. На сумісність з віддаленого SIP вузлів інших типів, наприклад IP-АТС або SIP шлюзів телефонної мережі загального користування новий клас TrustedDomain дає змогу застосунку вказати довільне віддаленого SIP-вузлів. Щоб отримати додаткові відомості див. матриця віддаленого SIP-вузлів, що підтримується Microsoft Exchange Server 2010. Ось приклад коду для нового 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
      }
    • Докладні відомості про режим сумісності з віддаленого SIP вузлів, відмінних від Microsoft Office Communications Server 2007, R2 наведено нижче.

      • Підтримка проекту ICE v6.0 та проект v19.0 вимкнуто.
      • Усі "ms-" заголовки, крім "ms діагностики" фільтрується з повідомлення.
      • Язку показники якості не публікуються на віддаленому SIP-вузлів. Замість цього показники послідовно є зібрані застосунку, якщо він доступний.
      • Додано підтримку SDP менше запрошення та повторне запрошення. Він надає сумісності сторонніх виробників виклик контролерів.
  • Підтримка за наступним чином:
    • Це виправлення, дає змогу застосунку авторів, щоб знайти ім'я або відхилення, які відбулися, перед тим, як ви отримали вхідний виклик.
    • CallReceivedEventArgs на основі InviteReceivedEventArgs. Таким чином, буде виявити ж API. Ось приклад коду:
      public abstract class InviteReceivedEventArgs : SipRequestReceivedEventArgs 
      {
      public DiversionContext DiversionContext { get; }
      }
  • Розширений виклик інсталяції, помилка діагностика та QoE наступним чином:

    • QoE показники, які зібрані застосунку після припинення на AudioVideoCall, в яких є AudioVideoFlow успішно створено. Щоб отримати додаткові відомості про показники QoE, відвідайте веб-сайт корпорації Майкрософт:http://msdn.microsoft.com/en-us/library/dd905463.aspx
    • Розробника програмного забезпечення може контролювати, чи, припинення дії з встановленим AudioVideoCall медіа-сеанс успішно створено. Для носіїв сеансів не вдалося розробник може надсилати запит діагностичну інформацію, що відноситься до сеансу неполадки носія. Ця інформація допомагає ведення журналу та усунення проблем підключення за протоколом віддалених користувачів. Ось приклад-коду:
      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; }
      }
  • Це виправлення, пропонує підтримку для дискретизації, на одному з потоку. Ця функція дозволяє, додаткові контроль дискретизації, на одному потоку (надіслати й отримати), в яких можна використовувати ставки для різних програм. Ось приклад коду:
    AudioSamplingRate AudioChannelTemplate.ReceiveDirectionSamplingRate (get/set)
    AudioSamplingRate AudioChannelTemplate.SendDirectionSamplingRate (get/set)

    AudioSamplingRate AudioChannel.SendDirectionSamplingRate (get)
    AudioSamplingRate AudioChannel.ReceiveDirectionSamplingRate (get)
  • Підтримка у групі факс-тони виявлення (CNG 1100 Гц) наступним чином:
    • Ця функція дозволяє, застосунки для виявлення, коли віддалений сукупність сигнал факсу. Якщо програма, підписані IncomingFaxDetected події, таким чином, що підтримуються корпорацією Майкрософт виявлено факсу:
      • Група (потоку RTP, надіслані за RFC 2833 CNG тони події)
      • Вихід із групи (CNG тони надсилається RTP події).
      Ось приклад коду:
      IncomingFaxDetectedEventArgs : EventArgs
      ToneController.IncomingFaxDetected
  • Підтримка швидкість відтворення наступним чином:
    1. Ця функція дає застосунки надати можливість відтворення WMA файлів, з різною швидкістю. Таким чином, щоб програми, для розробки інтерфейсів, надання користувачам ширших можливостей контролювати те, як вони споживають, вміст яких відтворення повідомлення може бути швидше або повільніше, залежно від швидкості відтворення, зазначену в застосунку.
    2. Виправлення, містить новий інтерфейс API-Player.PlaybackSpeed. Швидкість відтворення, може бути від половину нормальна швидкість two-times швидше, ніж звичайний швидкості.
  • Розширений Recorder наступним чином:
    • Існує кілька нові інтерфейси API, які вводяться в це виправлення. Клас запису є такі API. Цей клас дає змогу більш складні сценарії для розробки.
    • Програми за допомогою Recorder.Paused() можна призупинити записування вмісту. Програми за допомогою до Recorder.Start() можна відновити записування, у якому його було призупинено.
      Примітка. Recorder.Start() починається на початку файлу, якщо раніше називається Recorder.Stop(). Новий API-це Recorder.Paused і RecorderState.Paused.
    • Програми за допомогою VoiceActivityEvent можна визначити, чи вміст "Голос" або "Не голос". З цієї інформації програми можна використовувати ці події Обрізування Аргентина непотрібні файли, записані за стежити за шкали часу подій. Новий API-це клас для Recorder.VoiceActivityChanged VoiceActivityChangedEventArgs: EventArgs.
    • Користувачі також підтримує нові кодування формату файлу, який дає застосунки нові можливості, як результат записування файлів. На додаток уже підтримуваних форматів WMAAudio@16Kps такі підтримуються:
      • WMA48 - WMAudio, @ 48-Кбіт/с
      • PCM16K - PCM, @ 16 кГц, 16 біт на зразок
      • PCM8K-PCM, @ 8 кГц, 16 біт на зразок
    • Ось для нового API, зразок коду:
      WmaFileSink.EncodingFormat {get;set;}
      enum WmaEncodingFormat

Стан


Корпорація Майкрософт підтвердила існування цієї неполадки у продуктах Майкрософт, перелічених у розділі "Застосовується до".