For Sale

Hey I just announce that this blog


For More information or +966 5909 33 0 55


Adding Custom Commands to Lync Client Menus

We will discuss one of the ways in which the Lync client can be customized by offering contextual options that are specific to your own business needs which is creating custom menu items.

If you want to add your custom Lync application shortcut to the Lync Client you have to use the custom commands. The term “contextual conversations” comes up a lot in working with Lync. As Lync becomes more and more integrated into people’s workflows, it can automate much of this sending and retrieval of appropriate context, saving time and increasing productivity.

Use custom commands embedded in the Lync client UI to launch applications on the Microsoft Windows desktop. these custom commands are menu items added by the developer to the Lync client UI. You can add the custom commands to Lync client menus and pass the SIP Uniform Resource Identifier (URI) of the current user and selected contacts to the application that the custom command starts.

The custom commands that you add can appear on one or more of the following menus:

  • The Tools menu, on the menu bar in the Lync main window
  • The shortcut menu for contacts in the Contacts list
  • The More options menu, in the Conversation window
  • The shortcut menu for people listed in the Conversation window participant list
  • The options menu in a contact card

When you open Lync now, and right-click on a contact, menu items appears as follow:

Context Menu

You can define custom commands for two types of applications:

  • Apply only to the current user and are started on the local computer.
  • Involve additional users, such as an online collaboration program, and must be started on each user’s computer.

The custom command can be invoked in the following ways:

  • Select one or more users, and then choose the custom command.
  • Start a two-party or multiparty conversation, and then choose the custom command.

Adding Custom Command

To add a custom command for an application, add a registry subkey and the registry entries described in this topic.

Registry subkey is the application GUID, added at the following locations:

  • Lync Client 2013, 32-bit OS:
  • Lync Client 2013, 64-bit OS:
  • Lync Client 2010, 32-bit OS:
  • Lync Client 2010, 64-bit OS:

Registry entries under each GUID subkey, add the entries described as follow

Entry Type Description
Name REG_SZ The name of the application as it appears in the Lync UI.
Path REG_SZ The full path of the application along with parameters, including the default parameters of %user-id% and %contact-id%. The parameters pass a string representing the SIP URI of the user signed in to Lync and the selected contact or contacts to the application launched.
ApplicationType DWORD 0 = Executable, 1 = Protocol.
ApplicationInstallPath REG_SZ The full path of the executable, which is required if ApplicationType is 0.
SessionType DWORD 0 = local session, 1 = two-party session, 2 = multi-party session.
ExtensibleMenu REG_SZ A semicolon-delimited list of places where the command appears. Possible values include MainWindowActions, MainWindowRightClick, ConversationWindowActions, ConversationWindowRightClick, and ContactCardMenu. If ExtensibleMenu is not defined, the default values of MainWindowRightClick and ConversationWindowActions are used.

Examples show usage for HTML and .exe paths:

c:\\ext_menu.exe /userId="%user-id%" /contactId="%contact-id%"

See Also the following Registry Editor (.reg) files as examples:

Windows Registry Editor Version 5.00
"Name"="Code 4 Lync Custom Application"
"Path"="C:\\YourApp.exe /userId=%user-id% /contactId=%contact-id%"
"Name"="Code 4 Lync Custom Application"
"Path"="C:\\Program Files (x86)\\YourApplication\\YourApp.exe %param1%"
"ToolTip"="tooltip text"

Using Custom Command

The following table describes how to launch an application with a given ExtensibleMenu value.

ExtensibleMenu value Action
MainWindowActions In the upper-right corner of the Lync 2013 conversation window, click the Show menu button, point to Tools, and then click the custom command.
MainWindowRightClick In the conversation window, right-click a contact in the Contact List or Search Results pane, and then click the custom command.
ConversationWindowActions In the lower-right corner of the conversation window, click the More options ellipse, point to Actions, and then click the custom command.
ContactCardMenu Click the custom command on the contact card Options menu.

To test your custom menu by retrieve the %user-id% and %contact-id% arguments, add C# code to the application launched by the custom command.

static void Main(string[] args)
  if (null == args || args.Length == 0) Console.WriteLine("No args");
    foreach (string arg in args)
      Console.WriteLine("Arg: " + arg);

Removing Custom Command

Removing the GUID subkey removes the appropriate custom commands from the Lync UI.

MSPL Script How-to

Microsoft SIP Processing Language [MSPL], is a scripting language that you can use to customize how Lync Server handles and routes SIP messages. MSPL scripts run in the context of the Lync Server process itself (in the front end), so they can intercept messages between users, filter messages, reroute messages, and so on.

MSPL unlike UCMA applications, they don’t run as a separate process, nor do they create endpoints of their own. they aren’t limited to controlling messages to and from a single endpoint it deals with all endpoints of that Lync Server.

How you can decide to use MSPL or UCMA?

  1. MSPL
    • The MSPL code itself is included directly in the application manifest.
    • The MSPL modifies the Front End behavior of the Lync Server. It has control over every message that is proxied through the Front End Server, regardless of where it comes from which endpoint or where it goes.
  1. UCMA
    • The UCMA application runs on a separate server from Lync Server, and creates an endpoint which communicates with other Lync endpoints via the Lync Front End Server.
    • The UCMA application can participate in and control a conversation between the remote endpoint and itself but can’t control other conversations between other endpoints that are not in the same conversation.


MSPL Script Structure

The following is the form that your MSPL script must be which is an ordinary XML file. The application Manifest is an XML file can be edited using any XML editor, Text editor or even you can open it using Microsoft Visual Studio, so you will find it started with the xml declaration, The following script to filter the sip requests that used to join conference as follow:

<?xml version="1.0" ?>


    <!-- Define properties of the application -->
    <lc:requestFilter methodNames="INVITE" 
    <lc:responseFilter reasonCodes="NONE" />
    <lc:proxyByDefault action="true" />

    <!-- The message filtering script -->

if (sipRequest && (sipRequest.Method == StandardMethod.Invite)) 
    if (sipRequest)
        Log("Event", false, "Joined the conference");
	DispatchNotification("OnRequest", sipMessage.To);


MSPL Script Syntax


the root element of the MSPL script is the <lc:applicationManifest> it contains the appUri attribute, which is basically a unique identifier for your application and you need it when you installing your application to the Lync Server.

<lc:requestFilter methodNames="INVITE" strictRoute="false"/>

Using the <lc:requestFilter> you can control what types of messages this application should handle so it controls the types of requests. it contains the methodNames attribute which can contains a list of SIP method names separated by commas i.e. invite also can monitor ALL method names or NONE of them. the next one is strictRoute attribute, which is false by default, controls whether the application sees requests for which explicit routing details have already been specified. If this is set to true, these messages that have a “strict” route will also go through the application.

<lc:responseFilter reasonCodes="NONE" />

The <lc:responseFilter> also specify what types of messages this application should handle and contain The reasonCodes attribute holds a comma-delimited list of SIP response codes, or ALL, or NONE.

<lc:proxyByDefault action="true" />

The <lc:proxyByDefault> element, which is used to decide how application will handle the sip message by setting the action attribute, If this is set to false, any messages that are not proxied, responded to, or otherwise handled by the application are simply dropped. If it’s true, messages that are not handled are proxied to their destination by Lync Server, just as they would were the application not installed.

<lc:scriptOnly />

If application will consist only of an MSPL script, and will not use any managed code, we can add the <lc:scriptOnly /> element, if not there is no need to add it.

    <![CDATA[ /* Start writing your script here */ ]]>

After that The MSPL script itself is included in the manifest within the <lc:splScript> element.

if (sipRequest) {
    /* do something */
    Log("Event", false, "Log somthing - ", sipMessage.To);
if (sipResponse) {
    /* do something else */

If you need to access the message. The sipMessage variable provides access to a class that contains the message details. However, in many cases, the application’s behavior will depend on whether it is handling a request or a response; and the data available will depend on which type of message it is. the same as sipResponse if you want to access the response.

Helpful References

Inside UCWA

The Unified Communications Web API (UCWA) is a REST-like API to enable real-time communications over the web on Server-Side based works for Microsoft Lync on-primes. See the UCWA previous post

Technology Boundaries

  • Only users homed on a Lync Server 2013 pool can take advantage of UCWA capabilities.
  • Supported only for The On Prime Lync Server.
  • Server-to-server authentication between an on-premises server and an Office 365 component is not supported.
  • HD Photos, Voicemail and meetings are dependent on the version of Exchange Server 2013.
  • Supported only for The On Prime Exchange Server.
  • Exchange 2010 On prime and Online are not supported.
  • Compatible with Internet Explorer versions 9 and 10 are both supported, as are the latest versions of Chrome, Safari, and Firefox.
  • The developers needs to know HTTP: POST and GET and PUT and DELETE and HTTP headers, REST SERVICE and indeed JavaScript and JQuery.

What We Can Do With The Technology

  1. Contacts and Groups
    • Access, search, federated organizations, monitor on contact list, subscribing to the presence, Presence, Location, and Note can publish and view her presence and note, View own photos or the photos of their contacts.
  2. Two-party and Multi-party IM
    • Supports instant messaging between two parties in a peer-to-peer fashion as well as multi-party IM sessions that are hosted by the server.
    • Add Participant for a Multi-Party IM.
    • Escalate the conversation to conference.
  3. Working with Online Meetings
    • Schedule an online meeting that can be joined by via this API or there Lync services.
    • Joining of online meetings with messaging and phone audio modalities (for future use).
    • A roster of meeting attendees is provided; this information includes participant name, contact information, and modalities. And can update Meeting.
    • Exchange APIs can be used to place meeting information on the user’s calendar you will only see meetings created by UCWA.

Technology Barriers (What we can’t do)

  • No Audio, Video or other Real Time Media (at this time). According to the Channel 9 video, UCWA is on the Roadmap to get voice/video/screen sharing capability over IP after Lync 2013 goes RTM.
  • Only allow you connect at a user level i.e. can’t do action on behalf of others.
  • No Office 365 support.
  • No User Impersonation.
  • No custom presence Support.
  • Can’t start group IM conversations.

Development Ability

  1. People
    • Search.
    • Presence Subscription and Presence Subscription Membership.
    • Get contact and contact information i.e. Location, Note, Photo, Presence, Privacy Relationship and Supported Modalities.
    • Get group, Group Contacts, Default Group, Distribution Group, Expand Distribution Group.
    • Start/Refresh/Stop Subscription to Contacts and Groups.
    • Subscribed Contacts.
    • Subscribe To Group Presence.
    • Get contacts forward call information i.e. Immediate Forward Settings, Immediate Forward to Contact, Immediate Forward to Delegates and Immediate Forward to Voicemail.
  2. Me
    • Call Forwarding Settings.
    • Change Phone Number.
    • Change Visibility: Changes the visibility of a phone number to other contacts.
    • Change location.
    • Presence: get a representation of the user’s availability and activity.
    • Note, Photo and Report My Activity: Indicates that the user is actively using this application.
    • Call settings i.e. Reset Unanswered Call Settings, Simultaneous Ring Settings, Simultaneous Ring to Contact, Simultaneous Ring to Delegates, Simultaneous Ring to Team, Unanswered Call Settings, Unanswered Call to Contact and Unanswered Call to Voicemail.
  3. Online Meetings
    • Dial in Region: get a representation of the access information for phone users who wish to join an online Meeting.
    • Group.
    • My Assigned Online Meetings.
    • My Online Meetings.
    • Online Meeting Default Values: get a representation of the values of my Online Meeting properties if not specified at scheduling time.
    • Online Meeting Eligible Values: get a representation of the eligible values that the application can choose from when scheduling an Online Meeting.
    • Online Meeting Extensions: get a representation of the data that is needed by a custom meeting extension, stored as a collection of key-value pair properties.
    • Online Meeting Invitation.
    • Online Meeting Invitation Customization.
    • Online Meeting Policies.
    • Meeting Organizer.
    • Phone Dial in Information.
  4. Communications and Modalities
    • Accept/decline incoming conversation.
    • Send invitation to contact/Participant and knows the Acceptance state.
    • Add Messaging.
    • Add Participant.
    • Attendees.
    • Cancel/Reject.
    • Conversations: get a representation of the user’s ongoing conversations.
    • Data Collaboration to return the current modality.
    • Demote: user can demote the participant from leader to attendee in the online Meeting.
    • Derived Conversation.
    • Derived Messaging.
    • Disable/Disable Audience Messaging and Disable/Disable Audience Mute Lock.
    • Failed Delivery Participant.
    • Forwarded By.
    • From: get a representation of the participant that sent an invitation.
    • Hold Phone Audio.
    • Join Online Meeting.
    • Leaders.
    • Lobby.
    • Local Participant.
    • Messaging and Messaging Invitation.
    • Mute Audio/Video.
    • Participant.
    • Participant Application Sharing : track when a participant joins or leaves this modality.
    • Participant Audio : track when a participant joins or leaves this modality.
    • Participant Data Collaboration: track when a participant joins or leaves this modality.
    • Participant Invitation.
    • Participant Messaging.
    • Participant Panoramic Video.
    • Participant Video.
    • Phone Audio Invitation.
    • Promote.
    • Reject.
    • Resume Phone Audio.
    • Send Message.
    • Set Is Typing.
    • Start Messaging.
    • Start Online Meeting.
    • Start Phone Audio.
    • Stop Messaging.
    • Transferred By.
    • Typing Participants.
    • Video Locked On Participant.

Endpoints of UCMA Applications

Network Endpoints

The Network endpoints are the agents that Microsoft Lync uses internally in the UCMA applications to represent the users’ agents in code by creating instances or objects of the UserEndpoint class or the ApplicationEndpoint class and can handle all operations that concern a single user agent with the assistant of other related classes.

UCMA application can run without any endpoints, but it would not be able to do any useful services or tasks because the application would have no SIP user agents to send or receive messages. Therefore, any useful UCMA application must when starting up initialize and establish at least one user endpoint or application endpoint.


The UserEndpoint class allows an application to perform communication operations on behalf of a single Lync Server user. When established, the user endpoint always registers with Lync Server and retrieves presence and contact information for specific user. Through the UserEndpoint class, you can perform contact and contact group operations as well as publish a presence, but because the user endpoint represents a single user, an application cannot use it to perform trusted operations such as impersonating another Lync Server user.

The UserEndpoint class is best suited for an application that acts on behalf of a number of different existing users simultaneously such as Web – based client applications (like Communicator Web Access)

We can use it also in Contact and Group Operations to perform contact list operations and Publishing presence information for a user which automatically assigns access control information and instance IDs to presence elements.

The user endpoint is not as robust in recovering from connection failures as the application endpoint, so it is less appropriate for server applications that must be highly available. When a user endpoint loses connectivity with Lync Server, it attempts to re-register with Lync Server once, but if this attempt fails it gives up and makes no further attempts to recover the connection.


The ApplicationEndpoint class is acts for highly available server applications that provide a service to many different users simultaneously. It does not represent an individual user, it has a separate identity defined by a Contact object in Active Directory such as Automatic call distributors and Message broadcasting

Because an application endpoint is automatically trusted by Lync Server, it is able to “impersonate” any individual user in order to perform communications operations on behalf of that user.

The ApplicationEndpoint class is able to load – balance connections across several frontend servers. In addition, it is more persistent than the UserEndpoint class in recovering connectivity with Lync Server. When an application endpoint loses its connection to Lync Server, it goes into the Reestablishing state and tries to regain its connection with the server until it succeeds, regardless of how long it remains without a connection.

The application endpoint ’ s trusted status with Lync server allows it to perform conference operations that would otherwise be restricted to conference leaders, as well as some special operations that cannot be performed at all through the Lync client. It can also join conferences as a trusted participant; in this state, it is not shown in the conference roster and has the same rights as a conference leader.

Application endpoints are not able to perform any contact operations, nor can they publish presence.

PTZ Camera

What is the PTZ Camera?

PTZ is an abbreviation for pantilt, and zoom which reflects the movement options of the camera. A pan–tilt–zoom camera (PTZ camera) is a camera that is capable of remote directional and zoom control.

You can physically control the camera horizontally or vertically using electrical motors. The zoom is controlled by mechanically moving two lenses closer together or further apart dependent on whether you are zooming in or out with the effect that objects in view appear larger or smaller.

With these cameras you can now capture footage from 360° around the camera and digitally zoom in on certain areas. Because you are recording the entire field of view it doesn’t matter if you are zoomed in on the entry gates or not, all angles are recorded.

Pan and Tilt Control

On a conventional PTZ camera, when you pan and tilt you physically rotate the camera using electrical motors i.e. pan (horizontally) or tilt (vertically).

The movement of the motor could be controlled relatively or absolutely and this is depending on how much you want the camera to move steps or degrees. In addition to controlling the speed of the move.

The Pan and tilt motors also could have the signal to move without stop horizontally or vertically.

Zooming Control

In the Mechanical PTZ Cameras, zoom is controlled by mechanically moving two lenses closer together or further apart dependent on whether you are zooming in or out with the effect that objects in view appear larger or smaller.

Digital PTZ cameras don’t work in this manner. The camera will first capture a full image, usually in megapixel resolution. When a user decides to zoom in they are provided with a section of the overall picture. The pixels in this are then enlarged so that the cropped image is the same size as the original. This gives the appearance that you have zoomed in as objects are now larger.

Controlling the PTZ Camera

PTZ cameras could be controlled by any of the following ways

  • Control the PTZ camera by its remote control, not all vendors support remote controls and not all cameras support remote controls.
  • Controlling the PTZ camera by COM ports and it work with one of the following protocols PelcoP, PelcoD and VISCA
  • Controlling the PTZ camera by USB and it work with UVC and this can use some components like DirectShow.NET

We can implement the software component to control the camera using C++ and C#

Other Cameras’ Types

As stated earlier, conventional PTZ cameras use motors to move the camera around. There are multiple different ways of using these to pan the camera such as bands, cogs or direct drive. There are even some which use electromagnetism to accurately aim the camera in some higher end cameras.

Digital PTZ systems perform their functionality in software. As a result there are no moving parts and nothing to break, freeze or move. So long as the camera is functioning, the digital PTZ system will work. So from a reliability point of view, digital PTZ cameras win hands down.

(Source: Network Webcams)

Microsoft Lync 2013 SDK

Microsoft introduced the new Lync API release for Microsoft Lync 2013. Microsoft Lync 2013 SDK is the client-side API set that enables the integration and extension of Lync experiences.

With the Lync SDK, you can quickly add Lync 2013 features to an existing business application, extend the Lync client itself or, if you have the need, build a custom UI built atop the Lync client platform.

The Microsoft Lync 2013 SDK includes the Lync 2013 API, a managed-code (.NET) API that developers use to build applications that leverage the Microsoft Lync 2013 collaboration features. In addition to the Lync 2013 API, the Lync SDK includes a set of UI controls that can be used to add Lync features to a Microsoft Windows Presentation Foundation (WPF), or Microsoft Silverlight 4.0 application. The Lync 2013 SDK also ships with a set of working code samples and documentation to help you become a productive Lync developer as quickly as possible.

It is important to note the Lync SDK’s development model does require the Lync client to be installed on the user’s machine and the API is called from outside the Lync process, manipulating the same object model on which the Lync client is built.

Microsoft Lync Server 2013 SDK

The Microsoft Lync Server 2013 SDK includes the Microsoft Lync Server 2013 SIP Application API documentation, library (ServerAgent.DLL), application development tools, and sample applications.

The Lync Server 2013 SDK includes three Lync Server 2013 SIP Application API references that can be used to create Session Initiation Protocol (SIP) server applications that customize and extend the functionality of Microsoft Lync Server 2013:

  • SIP application manifest
  • Microsoft SIP Processing Language (MSPL)
  • Microsoft.Rtc.Sip namespace

This SDK is Intended for the Following Audiences

  • Developers who want to use application manifests and MSPL scripts to implement simple custom SIP message filtering and routing on computers in a Lync Server 2013 deployment.
  • Experienced SIP developers who want to create SIP-based managed code server applications that implement real-time content delivery or instant messaging infrastructure. This includes applications that work directly with SIP transaction objects or support multithreaded transactions.

What’s New

More than 70 new topics have been added to the SDK. These topics explain new features of Lync SDK as well as giving you a more in-depth look at features introduced in a previous release of the SDK.

New SDK Features

Lync SDK give you three new features will let you provide your custom application users with a complete collaboration experience. The three areas that we have enhanced the Lync SDK include:

  • Resource sharing. This feature allows a client to share a running process, desktop, or any one of the displays attached to a computer.
  • Persistent chat support. You can build a persistent chat client as well as a persistent chat add-in application that is attached to a persistent chat room.
  • On Line meeting content management. You can manage the contents of an on line meeting content bin, meeting content sharing stage, and meeting video display sources.

Most Solved Issues

Microsoft solved the problem of viewing the video in the UI Suppression Mode with the Lync 2013 SDK (preview) and now it is working fine but you need to install the latest release of the Microsoft Lync client (15.0.4454.1506) version

Related Information

Lync 2013 SDK training videos for developers
Lync 2013 Developer documentation
Download Microsoft Lync 2013 SDK

Introducing the Unified Communications Web API (UCWA)

The Unified Communications Web API (UCWA) is a new REST-like API to enable real-time communications over the web on Server-Side based works for Microsoft Lync on-primes and it is not supported for Office 365 till now.

The new UC Web API, or UCWA, in Microsoft Lync Server 2013 opens a new way of integration with many other client platforms. Lync Server 2013 UCWA brings Lync functionality to desktop applications, web applications and embedded devices with no need for Microsoft Lync client being installed and without Server side component either.

As you could remember with Lync 2010 if you want to create a client application for desktop or PCs you should use the Lync 2010 SDK and host it in any type of user interface like WPF or Silverlight also if you want to create and Add-Ons for the Microsoft Lync Server you need to use the UCMA but now UCWA makes customizations possible on any platform, device or application that can talk http and no browser plugin or ActiveX or Lync client is required with UCWA.

Features of the Unified Communications Web API (UCWA)

  • UCWA removes programming language dependencies.
  • No browser plugin required and No ActiveX dependency.
  • Lync client does not need to be running.
  • Built on top of UCMA.
  • REST-like API to create and work.
  • Simple data structures.
  • Embrace HTTP as an application layer.
  • Resource-oriented programming model.

What Developers Could Do and Access Using UCWA

  • Presence
  • Group Memberships
  • Contacts
  • Privacy Relationships
  • Scheduled Conferences
  • Search
  • Instant Messaging

What Developers Could Do and Access Using UCWA

  • No Audio, Video and any other media
  • No Conferencing only User level interaction
  • No Application Sharing

OAuth Token

The cool thing with the UCWA it Attempt to locate Autodiscover service and the Requested is redirected to OAuth endpoint to get a token and we have the features of the OAuth i.e. provide user credentials, Token is attached to every request header and Token establishes the user’s identity.

The (Representational State Transfer) REST has an Architectural pattern that sees the internet as a collection of resources available at unique locations (URLs\HREFs) so this approach is very great to enable us to create different types and models of applications for different platforms i.e. Linux Lync Client, Web Chat Lync client and Add Instant Message or Presence capabilities to any embedded device that can do HTTP.

Difference Between TCP and UDP

Before we talking about the most used protocols in the Transport Layer we should talk first about the Transport Layer, It uses a two-octet port number from the application layer to deliver the datagram or segment to the correct application layer protocol at the destination IP address.

There are two commonly used transport layer protocols: Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). In addition, there are two uncommon transport protocols: Stream Control Transmission Protocol (SCTP) and Datagram Congestion Control Protocol (DCCP), which are beginning to be used on the Internet. There is also Transport Layer Security (TLS) which provides security on top of TCP.

Transmission Control Protocol (TCP)

It provides reliable, connection-oriented transport over IP. A TCP connection between two hosts over an IP network is sometimes known as a socket.

TCP is a client/server protocol. Servers “listen” on a specific port for an incoming request to open a socket. A client sends a request to open a new socket to the server on the well-known port.

The combination of the source IP address, source port, destination IP address, and destination port identifies the socket connection. So it is possible for 2 hosts to have multiple TCP connections open between them.

TCP uses sequence numbers and positive acknowledgments to ensure that each block of data, called a segment, has been received. Lost segments are retransmitted until they are successfully received.

TCP sends data in units called segments. The maximum segment size (MSS) is negotiated between the hosts during the handshake, and is usually based on the maximum transmission unit (MTU) of the local network. A typical MTU value for the Internet is 1,500 octets.

TCP also has built in flow control. Flow control is used by a receiver to slow down the rate of transmission to allow the receiver to properly process or buffer incoming segments.

TCP uses a sliding window for end-to-end control. Senders can only send the number of octets in the window before waiting for an ACK. A receiver can reduce the size of the window in ACK messages, even setting it to 0 to cause the sender to stop sending. Once the receiver has caught up, another ACK can be sent to increase the window size and resume the flow of segments.

TCP adds a 20-octet header field to each packet, and is a stream-oriented transport. An application using TCP to send messages must provide its own framing or separation between messages. Error segments are detected by a checksum covering both the TCP header and payload.

Transport Port Numbers

Ports numbers are used by the transport layer to multiplex and de-multiplex multiple connections on a single host. Otherwise a pair of hosts could only have a single connection between them. Also, messages for different protocols can be separated by using different port numbers.

Port numbers are associated with a specific protocol. Others are registered to a particular protocol. Ports are a 16 bit integer.

Ports in the range 0 to 1024 are called well-known ports. For example, Web servers use the well-known port of 80

Ports in the range of 1024 through 49151 are known as registered ports. For example, SIP uses the registered ports of 5060 and 5061

Ports in the range of 49152 through 65535 are known as dynamic, private, or ephemeral ports. For example, RTP usually uses a dynamic port.

User Datagram Protocol (UDP)

It provides unreliable transport across the Internet. It is a best-effort delivery service, since there is no acknowledgment of sent datagrams. Most of the complexity of TCP is not present, including sequence numbers, acknowledgments, and window sizes.

UDP does detect datagrams with errors with a checksum. It is up to higher layer protocols to detect this datagram loss and initiate a retransmission if desired.

UDP is best suited for short, single packet exchanges such as DNS or routing queries. It is also good for real-time, low latency transports protocols such as SIP and RTP.

UDP adds an 8-octet header field to datagrams. Applications and protocols that use UDP must do their own framing—they must break up information into individual UDP packets. For a message oriented protocol, this typically means one message or request per UDP datagram.

Transmission Layer Security (TLS)

It is based on the Secure Sockets Layer (SSL) protocol first used in Web browsers. TLS uses TCP for transport although it has recently been extended to also run over UDP. TLS is commonly used today on the Internet for secure Web sites using the secure HTTP (https) URI scheme.

The TLS protocol has two layers: the TLS Transport Protocol and the TLS Handshake Protocol.

The TLS Transport Protocol is used to provide a reliable and private transport mechanism. Data sent using the TLS Transport Protocol is encrypted so that a third party cannot intercept the data. A third party also cannot modify the transported data without one of the parties discovering this.

The TLS Handshake Protocol is used to establish the connection, negotiate the encryption keys used by the TLS Transport Protocol, and provide authentication.

However, TLS transport has clear security advantages over UDP or TCP. TLS is widely supported due to its use in secure Web browsers and servers.

Understanding Lync in UI Suppression Mode and Set the Registry

Start developing apps that uses Lync SDK in UI Suppression mode, you must understanding the tradeoffs that you’re making is important; i.e. you are responsible for creating custom versions of almost the entire Lync client user interface. Additionally, your application has to programmatically sign the user into the Lync client using a custom login interface that you are also responsible for creating.

All the user interface elements of the Lync client are not visible when it is running in UI Suppression mode except the VideoWindow control that is used to render video. The VideoWindow control is only available when running in UI Suppression mode. Later in this chapter, you learn how to access the VideoWindow when working with conversations that use the AudioVideo modality.

The Lync controls are not available when the Lync client is running in UI Suppression mode; they are automatically grayed out and disabled. You must create your own custom versions of controls.

Automation is also unavailable when running in UI Suppression mode. Automation provides an easy way to start conversations in all modalities; however, it relies on Lync user interface elements such as the conversationwindow.

Configuring Lync UI Suppression

Lync UI Suppression mode is configured in the registry. When the Lync client is put into UI Suppression mode. To put Lync into UI Suppression mode, you must create and set a registry key called UISuppressionMode in the appropriate location in the Windows registry depending on whether you’re running the 32 – bit or 64 – bit version of the Lync client.

After Setting the Registry to run the Lync client in UI Suppression Mode the client is disappeared and doesn’t opened unless you update the registry again to run outside of UI Suppression Mode

Enable UI Suppression mode in the Lync Client 32-bit Version

Create a key in the registry and name it UISuppressionMode and set its value to 1 in the following location: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Communicator

Windows Registry Editor Version 5.00


Enable the UI Suppression mode in the Lync Client 64-bit Version

Create a key in the registry and name it UISuppressionMode and set its value to 1 in the following location: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Communicator

Windows Registry Editor Version 5.00


Disable the UI Suppression mode in the Lync Client 32-bit

Set the UISuppressionMode registry key value back to 0

Windows Registry Editor Version 5.00


Disable the UI Suppression mode in the Lync Client 64-bit

Set the UISuppressionMode registry key value back to 0

Windows Registry Editor Version 5.00


(Source: Professional Unified Communications Development with Microsoft Lync Server 2010 by George Durzi and Michael Greenlee)