4/30/2010 2.08 Editorial Revised and edited the technical content 6/7/2010 2.09 Editorial Revised and edited the technical content 6/29/2010 2.10 Editorial Changed language and formatting in the technical content. 7/23/2010 2.10 None No changes to the meaning, language, or formatting of the technical content. 9/27/2010 3.0 Major Significantly changed the technical content. 11/15/2010 3.0 None No changes to the meaning, language, or formatting of the technical content. 12/17/2010 3.0 None No changes to the meaning, language, or formatting of the technical content. 3/18/2011 3.0 None No changes to the meaning, language, or formatting of the
technical content. 6/10/2011 3.0 None No changes to the meaning, language, or formatting of the technical content. 1/20/2012 4.0 Major Significantly changed the technical content. 4/11/2012 4.0 None No changes to the meaning, language, or formatting of the technical content. 7/16/2012 4.0 None No changes to the meaning, language, or formatting of the technical content. 10/8/2012 4.1 Minor Clarified the meaning of the technical content. 2/11/2013 4.2 Minor Clarified the meaning of the technical content. 7/30/2013 4.3 Minor Clarified the meaning of the technical content. 11/18/2013 4.3 None No changes to the meaning, language, or
formatting of the technical content. 2/10/2014 4.3 None No changes to the meaning, language, or formatting of the technical content. 4/30/2014 4.3 None No changes to the meaning, language, or formatting of the technical content. 7/31/2014 4.4 Minor Clarified the meaning of the technical content. 10/30/2014 4.4 None No changes to the meaning, language, or formatting of the technical content. 3/30/2015 4.4 None No changes to the meaning, language, or formatting of the technical content. 9/4/2015 5.0 Major Significantly changed the technical content. 7/15/2016 5.1 Minor Clarified the meaning of the technical content.
Application Sharing Extensions (as described in [MS-CONFBAS]) that relate to application sharing media content that is transferred using the and hosted by Communications Server. XML Schema for Media Control Extensions Extends the message semantics for carrying video control messages in SIP INFO methods. In multiparty video sessions, these extensions provide a mechanism that freezes unused video streams, thereby minimizing the load on the network. HTTP Protocols The following table describes protocols used by clients to communicate with communication server components using HTTP to consume real time communication services for signaling. Protocol name Description Short name Microsoft Online Conference Scheduling and Management Protocol Describes the protocol used to communicate with Unified Communications Web API components of the Lync Server to enumerate, create, delete, and edit scheduled online conferences hosted by the Lync Server. Lync Autodiscover Web Service Protocol Describes the protocol used to determine where to access specific Lync resources, including Lync web services and SIP entry points. Unified Communications Call Via Work Protocol Specifies the protocol that defines how an application can create a PSTN call between a desktop or mobile phone and a remote party. Unified Communications Event Channel Protocol Specifies the protocol that describes a mechanism that web applications can use to retrieve notifications changes to resources. Media Protocols The following protocols describe the use of the Real-Time Transport Protocol (RTP) and protocols to authenticate protocol clients for Communications Server and identify the way audio and video traffic is established over the Internet. Real-Time Protocols Protocols in this table enable transmission of real-time data between multimedia . The Real-Time Transport Protocol (RTP) is a set of network transport functions suitable for applications transmitting real-time data, such as audio and video, from one multimedia endpoint to one or more multimedia endpoints. During a Communications Server conference that includes audio, video, desktop, or application-sharing data, the protocol client connects to the Audio/Video/Application Sharing Conferencing Server, and media is exchanged through the RTP. An RTP session is established using SIP/SDP, which manages the negotiation for the RTP session, including defining the transport, payload, and security parameters. The RTP and its associated control protocol, , are formally described in . In addition, defines the set of payload-type codes and payload formats for audio and video.
Federated links Public IM providers Gateways Server applications The following sections summarize these systems. Systems such as gateways and public IM providers can interface with Communications Server at the protocol level over the IP network. Communications Server also provides a number of programmable interfaces (APIs) to abstract these wire protocols, simplify connectivity, and make it possible to support a wide variety of systems that can connect to Communications Server: Unified Communications Client SDK (UCC) Office Communicator SDK (OC Automation) Office Communicator "14" SDK SIP-Based Clients Protocol clients capable of communicating with Communications Server directly over SIP are referred to as SIP-based clients, because they support a native SIP stack. Such protocol clients offer a SIP stack that is interoperable with the SIP and media extensions of Communications Server. Examples of SIP-based clients are software-based protocol clients such as Office Communicator, and SIP-based phones such as Office Communicator Phone Edition and Office Communicator Mobile. Federated Links Organizations using Communications Server can allow their users to communicate with users from other enterprises over a federated link. A federated link is established between the two organizations to allow these communications. Some federated links can be established using described in and . Public IM Providers Communications Server can interoperate with public IM providers such as AIM, Yahoo!, and MSN. This interoperability allows external users signed in to any of these providers to communicate over IM to an enterprise user connected to Communications Server as long as there is a public IM connectivity established between the enterprise and the public IM provider. Gateways Gateways provide interconnectivity between the Communications Server network and other networks such as PBX, PSTN, XMPP, and other non-SIP-based networks. Gateways extend the connectivity reach of users signed in to Communications Server into non-SIP-based networks. Examples of gateways include: SIP/PSTN gateways RCC gateways IP-PBX
Server Applications Server applications can be as services using Communications Server’s highly scalable API, UCMA 2.0, or MSPL services. Such services provide specialized functions in addition to the functionality provided by Communications Server. Examples of such services include Exchange Unified Messaging and ForeFront Security for Communications Server. Dependencies on Other Systems/Components The Communications Server system depends on systems in order to function: Active Directory directory service DNS service Certificate authority service Microsoft Service Message Queue Hardware load balancers Exchange Unified Messaging Gateways Microsoft Office Web Access Companion Server The following sections outline these systems. Active Directory Communications Server is dependent on Active Directory domain controllers to provide authentication services and security policies. These domain controllers provide an LDAP-enabled directory service (DS) that stores users’ information such as name and SIP URI. DNS Service is required so that Communications Server and protocol clients can resolve host names to IP addresses (A records), resolve SRV records, and route SIP traffic accordingly. The DNS service plays an integral role for both internal (within the organization) and external communications routing. Certificate Authority Service Communications Server uses certificates to perform strong authentication of protocol servers before Transport Layer Security (TLS) communications can be established. This authentication mechanism relies on a trusted . Internet Information Services Communications Server requires Internet Information Services (IIS), to be configured in order to service users using the HTTPS protocol for address book downloads, distribution list expansion, and Web conferencing document-sharing.
The protocol client acknowledges the message from the previous step with a SIP 200 response. The protocol server also sends the historic backchat to the protocol client by sending a "rpl:bccontext" reply over a SIP INFO message, as described in [MS-XCCOSIP]. The protocol client acknowledges the message from the previous step with a SIP 200 response. The protocol client can post a chat to the room by sending a "grpchat" command over a SIP INFO message, as described in [MS-XCCOSIP]. The protocol server acknowledges the message from previous step with a SIP 200 response. The protocol server replies with a "grpchat" reply over a SIP INFO message, as described in The protocol client acknowledges the message from the previous step with a SIP 200 response. Post-conditions Protocol client has an established chat session that can be sued for transferring messages, notification of activity (like chat participants joined/left), invitation status, and so on. Versioning, Capability Negotiation, and Extensibility Versioning Communications Server provides the capability for IT administrators to control which versions of Office Communicator can be used to can sign in. This control is enforced by checking the UserAgent attribute in the SIP header sent by the protocol clients. If the UserAgent header does not meet the minimum version number required, Communications Server rejects the protocol client’s sign-in request for the user. Extensibility Communications Server provides enhanced presence, which makes it possible for IT administrators to extend the presence model with additional information about users. Such extensions can be publishing location coordinates (GPS), displaying cellphone status, and so on. Exposing these additional presence extensions requires modifying the protocol clients to be aware of them and to appropriately display them in the user interface (UI). Error Handling Many error conditions can occur with Communications Server. Also, Communications Server is dependent on the successful operation of other systems. An exhaustive list of possible failures is not within the scope of this overview document; however, the following list provides categories where error conditions can occur. Possible failures caused by dependent systems: Unavailability of a Global Catalog (GC) server for Active Directory requests. DNS is not properly resolving protocol server qualified domain name (FQDN) or SRV records are not configured properly. The certification authority (CA) that is used to issue certificates to Communications Server is not configured to be trusted by a protocol server or protocol client.
60 61 59 58 58 start a conference, join with multiparty audio, and start application-sharing ( 63, 64) 26 Expand a distribution list 35 55 66 23 24 24 24 24 24 F 24 13 13 G Gateways 26 24 Get an address location 32 7 H 55 26 20 I 25 24 66 56 56 56 56 56 56 56 56 57 10 26 Initiate a call from a client 38 Initiate instant messaging 36 22 25 7 J Join a chat room 52 M 59 21 66 26 25 MS-AVEDGEA 56 MS-DLX 56 MS-ICE 56 25 MS-OCER 56 MS-SDPEXT 56 MS-SRTP 56 MS-TURN 57 O Overview 17 21 22 21 18 20 20 18 17 13 P Perform client bootstrap 30 Perform registration and authentication 28 Perform the sign-in process 33 26 R 21 10 Requirements 55 55 13 26 S