Archive for the ‘Lync EV’ Category

Outbound Account Codes in Lync 2010 – How to use them

November 14, 2012 Leave a comment

One of the features often used with legacy phone systems are what are known as Account Codes.
Account Codes are a method of tracking outbound calls, and grouping them together. For example, suppose your company performs outbound calls for a set of clients that have hired your company to create appointments for those clients’ sales people. People, (“agents”), might be placing calls on behalf of client “A”, and then later in the day on behalf of client “B”. Your company would like to track, and group the calls made by the agents for clients “A” and clients “B”. The purpose being so that your company’s clients are billed for that portion of your company’s service.
Legacy phone systems have long had the ability to allow a calling person to enter an outbound phone number followed by a two digit code, (“Account Code”). These correspond to the client they are making calls on behalf of. For example, Agent Sally might enter “208 555 5000”, wait for a double beep, and then enter “82” as the Account Code. The PBX and/or the local carrier will then remove the “82”, and the PBX and/or the carrier will store the phone number and Account Code entered. At a later time the Telecom admin can produce a report that shows what numbers were dialed with the corresponding Account Codes for billing purposes.

Question: How can a similar process be addressed in Lync 2010?

Answer: If you have Lync 2010 deployed with Enterprise Voice utilizing a media gateway, then the media gateway can be used to manage entered Account Codes. The idea is that you have callers enter a phone number in the format of: “Account Code” + “Dialed Number”, (e.g. 82 208 555 5000). Then configure your media gateway to remove the Account Code prior to sending on to the PSTN. You simply create an outbound “rule” on the gateway for each Account Code. For US dialing you should make sure that your rule looks for the Account Code, and that the total number length is 12. You might also have a rule that checks for the Account Code at the start, (i.e. first two digits), and that the total is either 12 or 13 digits, (i.e. account for 11 digit dialing).
Once you are collecting this data, then you can utilize the Lync 2010 Monitoring server to collect this data and then report against it. Dell/Quest’s MessageStats will even “pull” the Lync Monitoring Role data in to their database, and provides some very nice reports, (e.g. break out by area code, Outbound numbers, etc.). All of which can be exported easily to Excel for further manipulation.

Categories: Lync, Lync EV, Uncategorized

Using Exchange 2010/2013 UM for voice mail for either Lync users or legacy PBX users at the same time

November 13, 2012 Leave a comment

Exchange 2010 SP1 supports what are known as Secondary Dial Plans.

These are very useful for a situation where Exchange UM may be taking messages for Lync, but you also have users who are not on Lync, or Lync is not yet their primary phone. However, you wish to have Exchange UM be their voice mail provider, (i.e. as part of the process of decommissioning your existing legacy voicemail).

To create a Secondary Dial Plan on your Exchange UM server, do the following steps here:


Note: make sure that prior to these steps you have performed the Lync to Exchange UM integration so that Lync can act as a “PBX” to route the un-answered calls from your Legacy PBX to Exchange UM.

To enable a user for Exchange UM, and allow your legacy PBX to utilize Exchange UM, (i.e. take messages for that user’s extension), the following steps should be performed. This is for a user who has not been enabled for Lync.

  •  Have the user provide their Legacy 4/5 digit extension and AD logon
  •  Sample: Alexander Bell – AD = Legacy PBX Ext: 5-2145
  •  Start the Exchange Management Console, (EMC)
  •  Locate Alexander’s mailbox
  •  Right click on Alexander’s entry and select “Enable Unified Messaging
  •  Click Browse, (for UM Policy)
  •  Select Legacy DialPlan and OK
  •  Select Next, (you may also enter their UM PIN but not necessary since Exchange will provide that PIN in an email that is auto generated)
  •  Click Next again
  •  Click Enable
  •  Instruct your telecom admin to “program” this extension on the Legacy “side” so that if a call is placed to this user’s extension, or they are on the phone, (“busy”), that it is not answered. Then needs to be routed to Exchange UM. Your telecom admin will know how to implement that routing. Just make sure to provide them with the IP address of the media gateway or Direct SIP trunk that routes to Lync. In the case of a Direct SIP, the Lync server(s) will route the transferred call to Exchange UM. This is because you will have already done the Lync/UM integration that allows Lync to route un-answered calls to UM.


Lync 2010 Response Groups, (RGS) not updated automatically when users SIP address change nor if they are removed from Active Directory.

November 1, 2012 3 comments

I recently worked with a client who I assisted with creating several Lync Response Groups that are used for Hunt Groups, (ring multiple phones at once for incoming calls) and IVR, (providing menu options for inbound calls and routing to various extensions).

My customer has built several Lync Response Groups by adding Agents, (those whose Lync phones will ring), under the Agents option of “Define a custom group of agents”.  Using this option you can add or remove “Agents”, (sip addresses), from a Lync Response Groups.

Un-expected behavior found: If a Lync enabled user’s SIP address changes or that person is removed from Active Directory, (e.g. the person leaves the company), we discovered that Lync Response Groups user names are not automatically removed.  In other words, the “Custom Group of Agents” does not behave like an AD group does when users are removed or their name changes.

Issue solved: If you wish to have Lync Response Groups agent lists change automatically there is another option:

  • Before you create a Lync Response Group, create an Email enabled distribution list.
  • For simplicity make the name of the email enabled AD distribution group the same as what you will call your Lync Response Group.
  • Then add the AD users that will be used by the Lync Response Group that you will create.
  • Now create your Lync Response Group but under the Agents option select “Use an existing email distribution list”.
  • Enter the email address of the email enabled distribution group that you previously created.  Make sure to check your spelling since the Lync admin tool does not validate the address entered.

Now when a user’s SIP address changes or they are removed from Active Directory your Lync Response Group Agent lists will stay current.  Please note that you can also change existing response groups by using the above process by creating distribution groups and changing the Agent option.  This can also be done with PowerShell cmdlets, but that is for another day…

Categories: Lync, Lync EV, Uncategorized

Why do they call it a Trunk anyway?

February 22, 2012 Leave a comment

Ever wondered why they call a phone trunk a “trunk”? Has this not been something keeping you awake at night?

In the interest of helping those losing sleep over this question, the following might provide some assistance:

A very long time ago when telephones were being installed, it was necessary to bury cables in the ground that would connect houses to the phone company offices, which then connected to what is now known as the PSTN, (Public Switched Telephone Network). These cables were 3 or 4 inches around, grey in color, and resembled the look of an elephant “trunk”. As cables were laid, and the PSTN network grew the name “trunk” stuck. The intern-connecting of these pacaderm appendages came to be known as the act of “trunking” 

Categories: Lync EV, Uncategorized

To E1 or to T1? – that might be the question

February 22, 2012 Leave a comment

I was recently working on a Lync engagement that involved deploying Lync Enterprise Voice to connect to a legacy PBX. In order to route calls to and from the legacy PBX, we needed to configured a media gateway and a Q.SIG trunk. Q.SIG is a protocol that runs on a T1 PRI. It was originally invented as an industry standard to allow PBX’s from different vendors to route calls to each other. Prior to Q.SIG, if you have a Nortel PBX, (“switch”), and an Avaya PBX, and you wanted to route calls, there was no way to do this because each legacy PBX vendor used their own proprietary protocols to route and communicate with their own PBXs.

Q.SIG was developed to allow different vendor PBXs to route and communicate calls. Q.SIG runs on a standard T1 PRI. The Q.SIG protocol contains various pieces of information such as the Called Number, (who you are trying to dial), and the Caller ID, (who is calling). In order to connect two PBXs with a Q.SIG trunk, each PBX is installed and configured with a Q.SIG “card” so that the T1 PRI cable, (i.e. what we call a standard RJ45 Ethernet cable), can connect the two. The connection can also be a leased line T1 but for simplicity I am using the cabling example.

It turns out that media gateways from the major vendors also support Q.SIG, so that if you want to integrate a legacy PBX supporting Q.SIG with Lync, then you can use a media gateway to do the protocol conversion by connecting the Q.SIG port on a media gateway to the legacy PBX, and then configure the Ethernet “side” of the media gateway to communicate with Lync.

Q.SIG running over a T1 PRI only supports 23 concurrent calls occurring between the media gateway and the legacy PBX. The reason that it is only 23 calls, is that a T1 is a 1.5 MB “pipe”. Since each call is dedicated 64 kb/s of bandwidth you then divide 1.5 mb/s by 64 kb/s and you get the number 23. You might notice that the “maths” does not quite come out as “23” but there is another channel called the “D” channel that provides the signaling, (i.e. start the call, stop the call, etc.). The “D” channel is the telephony version of SIP, whereas the voice channels are the media streams like RTP in the Lync “world”.

But what if you wanted to get a few more calls from your Q.SIG connection?

Turns out that the T1 standard is used in the US, and that the E1 standard is used outside the US. The E1 standard has 30 channels instead of 23, (still 64 kb/s) and total bandwidth of 1.5 MB/s. When Q.SIG was developed, the designers accounted for both the T1 and E1 standards. This means that when you set up the Q.SIG card on the PBX, you can have the PBX administrator set it to “E1” instead of “T1”, and on the media gateway set the gateway to use Q.SIG with “E1” instead of “T1”, and you will then get up to 30 concurrent calls between the PBX and the gateway & Lync.

Categories: Lync EV, Uncategorized

Integrating Lync with a T1: What to make sure you and the customer ask the phone company

February 22, 2012 Leave a comment

When integrating Lync with a T1 PRI via a media gateway there are some questions that you might wish to ask the customer prior to beginning the Lync / Telephony integration that can save you and the customer some time:

• For calls to the PSTN: How does the T1 PRI expect to receive the Called Number and Calling Number fields from Lync? For example, should those numbers be 10 digits or 11 digits or is the T1 provider capable of accepting both?
• For calls from the PSTN: How will the T1 PRI provider send the Called Number and Calling number fields to the media gateway? For example, while they be 10 digits, or 11 digits, (Phone providers other than SIP providers won’t send E.164).
• What T1 PRI protocol(s) does the T1 PRI that has been provisioned support, (e.g. NI2, 5ESS, 4ESS or DMS100)? This is needed to configure the media gateway to communicate with the T1 PRI.
o Make sure to avoid the customer purchasing a T1 PRI that is utilizing CAS. CAS does not support CallerID, (i.e. you won’t know who is calling)
• What phone numbers are being routed to the T1 PRI? For example, is it a block of numbers or a list of numbers out of sequence? If all numbers are going to a single Lync server/pool, then the gateway can be configured to route all calls on the T1 PRI to Lync’s IP address. However, if you have multiple locations you may need to set up routing tables on the media gateway that depending on the Called Number may dictate to which Lync server/pool the call is routed.
• Before going onsite ask the customer, “Has the T1 PRI local loop has been turned-up and accepted”. When a phone provider, (i.e. the CLEC) technician goes onsite, they will connect the T1 to a box known as a DMARC (demarcation point). At that time the phone technician will verify that the T1 can communicate back to the phone company, (i.e. the “CO” – central office). After that is done, the customer will be asked to call the phone provider, and “accept the local loop” for that T1. At that time, the customer should ask the person on the phone to verify that BOTH the data and voice channels are “up”. Very often a phone provider will “turn up” the data channel, (the “D” channel) and not “turn up” the voice channels, (really).
• After the T1 PRI “turn up” is verified, then make sure that the customer also calls the phone provider to accept the block of phone numbers, (i.e. DIDs) that have been provisioned. This is a separate call since it will be a separate work order for the phone company, (really). The customer should tell the phone provider to go ahead and “point” those numbers to the new T1 even though the media gateway has not been yet connected.

Hopefully this is helpful when rolling out a media gateway with Lync and a T1 PRI by saving you some time onsite engaging in thumb-twiddling exercises 

Categories: Lync EV, Uncategorized Tags:

A Unique and clever method for providing Lync and legacy phone co-existance with minimal user pain

February 2, 2012 Leave a comment

I recently have been at a client who has decided to move from Centrex based phones to Lync EV. This customer decided that doing a something like a weekend cut-over to Lync from their legacy phone system would be too drastic for end users, (about 15,000 people). This organization like many has legacy functions such as hunt groups, (e.g. 3 or 4 phones ring at the same time in a dept and anyone can answer). The team responsible for the move to Lync and eventual support of Lync decided that they needed a solution that allowed both “phone” systems to run in parallel so that users can use both Lync and their legacy phones while legacy functionality such as response/hunt groups can be migrated to Lync.

This customer came up with a somewhat unique and clever way allow Lync to run alongside the legacy system, and provide EV without changing the end user’s phone number. This particular customer is using Centrex, but this would easily apply to Cisco, Avaya, or other PBX infrastructures. This solution also has the added benefit of providing a path for the customer to stop using TDM voice and move to a SIP provider:

Lync and Centrex co-existence – how it is done:

• Customer purchased block of DIDs on a Windstream SIP trunk, (e.g. 202 475 xxxx)
• User is enabled for Lync and Lync EV
• User is enabled for Exchange UM for voice mail
• Current Centrix DID, (e.g. +1 303 444 1234) is saved as LineURI field (E.164 format)
• User is assigned a DID from the Windstream SIP trunk, (e.g. +1 202 475 1234)
• User’s SIP trunk DID is set as a Lync Unassigned number using set-csunassignednumber cmdlet
• A Lync Announcement is created that forwards calls to the unassigned SIP URI of the +1 202 475 1234 number to the LineURI of the user, (e.g. +1 303 444 1234). This is done by using set-csannouncement cmdlet BUT not assigning a greeting AND setting the -TargetURI parameter to the SIP address of the end users’ LineURI, (e.g. tel:+13034441234). This means that calls forwarded from the end users’ Centrex phone to their SIP trunk DID, (e.g. 1202 475 1234), to route to the unassigned number, ( +1202 475 1234) which plays NO greeting and itself is forwarded to the end users’ LineURI, (i.e. the -targetURI parameter of the set-csannouncement).
• At this point the following behavior occurs for a user:
o User maintains their current phone number
o User places calls from Lync via the SIP trunk and their CallerID is their Centrex number
o Calls placed to their Centrex number forward directly to their Lync client/phone
o If the user wishes to not receive calls on their Lync client they can turn off the autoforward. If they make calls from Lync their CallerID will still be their Centrex number
• At a later point in time the customer will begin porting the Centrex numbers over to the Windstream SIP trunk provider and start to get rid of Centrex phones.

Categories: Lync EV