Lync uses a number of different protocols to operate, and it can sometimes be confusing keeping track of which one does what. This is a short overview of the protocols in Lync and what they are for.
SIP (Session Initiation Protocol)
Session Initiation Protocol, a.k.a. SIP, is arguably the most important protocol for Lync. SIP is a standard protocol used by numerous communication platforms, and its purpose is, as the name says, to initiate sessions, although it’s been extended to serve other purposes as well, such as presence.
SIP is defined in RFC 3261 from the IETF, and that document is a good source for a basic understanding of the protocol. Lync adds some specialized extensions to the protocol, to handle things like authentication, call parking, compression, routing, and registration. Also, while most SIP-based communication platforms send SIP messages over UDP, Lync sends them over TCP, and, under normal circumstances, secures them with transport layer security (TLS). This is an important point to remember when integrating Lync with other SIP platforms or products.
SDP (Session Description Protocol)
When SIP endpoints are using SIP to start up a communication session, they need to exchange information about where media should be sent, and come to an agreement on things like the codec to be used for the media and what capabilities are allowed. In order to do this, they use Session Description Protocol, or SDP, in the body of the SIP INVITE message. SDP is described in RFC 4566, and consists of a series of key/value pairs, one on each line, with the key and value separated by an equal sign. Here’s an example:
v=0 o=- 12962505634775207 1 IN IP4 192.168.0.12 s=CounterPath X-Lite 4.1 c=IN IP4 192.168.0.12 t=0 0 a=ice-ufrag:6c3d1c a=ice-pwd:67b942ce283ee9d50fe8fc4dd2b67a04 m=audio 49492 RTP/AVP 107 0 8 101 a=rtpmap:107 BV32/16000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=candidate:1 1 UDP 659136 192.168.0.12 49492 typ host a=candidate:1 2 UDP 659134 192.168.0.12 49493 typ host
The process that the SIP endpoints go through to determine media settings is called the offer/answer process, and it’s described in RFC 3264.
Real-Time Transport Protocol (RTP)
The protocol that Lync uses to actually transmit media is Real-Time Transport Protocol, or RTP. It has a counterpart, RTCP, which transmits control information alongside the RTP stream. Both protocols are defined in RFC 3550. The main content of RTP packets varies widely depending on the media type and codec used.
Lync also uses RTP to transmit DTMF tones, the tones generated when you press keys on the phone keypad. The method for using RTP in this way is defined in RFC 2833.
Lync generally sends media via an encrypted form of RTP, called SRTP, but it can communicate in unsecured RTP if necessary (and if security settings allow).
Centralized Conference Control Protocol (CCCP or C3P)
To send commands to conferences and convey information about them, Lync uses the Centralized Conference Control Protocol, or C3P (sometimes CCCP). C3P consists of XML documents, which Lync sends in the body of SIP messages such as INVITE or INFO messages.
Persistent Shared Object Model (PSOM)
PSOM is the protocol used for web conferencing. It’s a Lync-specific protocol, and Microsoft has made protocol documents available for it.
Interactive Connectivity Establishment (ICE)
Lync uses a protocol called ICE, which itself uses two separate protocols, STUN and TURN, to get media to endpoints on the other side of a NAT firewall. Jeff Schertz has a fantastic and very detailed article about Lync’s usage of these protocols.
I’ve left out some of the very well-known protocols, like HTTPS, but if you want to see how all of these protocols, including the well-known ones, fit together, a great resource is the Microsoft Lync Server 2010 Protocol Workloads Poster, which shows everything graphically.
The Microsoft Office Protocol Documents page on MSDN has a number of documents describing the Lync-specific protocols and extensions to protocols.
If you have any other good resources to suggest, or if there’s an important protocol I’ve left out, please leave a comment.