If you are installing the Central Management Database (XDS) for a new Lync Deplyoment, you might run into an issue if the the SQL Server was installed much earlier than Lync will be.
Over the time the Model Database was increased to some new values.
It is necessary adjusting the Model Database in SQL back to 2MB, which is requried for initiating a new Database with the Lync integrated script.
Therefor you need to login to SQL Server and navigate to the System Databases and right cklick the MODEL DB and SHRINK it back (Database and File) to 2MB
The model database is an empty hull for each new database that should be created. If the size is not matching, you run into this common error.
In Lync deployment log, you will find the following error:
Feature: CentralMgmtStore 11.04.2013 10:18:10
└ SQL Instance: sql01.customer.com 11.04.2013 10:18:10
└ Collocated: False 11.04.2013 10:18:10
└ Found "RTCUniversalServerAdmins": True 11.04.2013 10:18:10
└ Found "RTCUniversalConfigReplicator": True 11.04.2013 10:18:10
└ Found "RTCUniversalReadOnlyAdmins": True 11.04.2013 10:18:10
└ InstallDatabaseInternalFailure: An internal error has occurred while trying to create or update the database. 11.04.2013 10:18:10 Error
└
Error: The CREATE DATABASE statement failed. The primary file must be at least 50 MB to accommodate a copy of the model database.
▼ Details
└ Type: SqlException
└ ► Stack Trace
Author: Thomas Pött Managing Consultant Microsoft UC
Lync MVP
MVP AWARD
Thursday, April 11, 2013
Wednesday, March 27, 2013
Lync 2013 CU1 Error : "Cannot find any suitable disks for database files. You must manually specify database paths."
If you are running the second step in upgrading Lync Server 2013 CU1:
Install-CsDatabase -ConfiguredDatabases -SqlServerFqdn SE.FQDN -Verbose
You might run into an error:
Error: An error occurred: "Microsoft.Rtc.Management.Deployment.DeploymentExecption" "Cannot find any suitable disks for database files. You must manually specify database paths."
Solution:
This error is simply a problem with your disk space.
You only need to make sure you have sufficient disk space left. As far as I figured out, you need at least 20GB left on your HDD.
Author: Thomas Pött Managing Consultant Microsoft UC
Thursday, March 7, 2013
Windows Process Activation Service termininated
If you encounter the following error on a Windows 2008 R2 or Windows 2012 Server with Exchange or Lync:
The Windows Process Activation Service encountered an error trying to read configuration data from file ‘\\?\C:\Windows\system32\inetsrv\config\applicationHost.config’, line number ’0′. The error message is: ‘Configuration file is not well-formed XML’. The data field contains the error number.
The only thing you have to do is:
copy a "healthy" applicationHost.config file in c:\inetpub\history and put it into c:\windows\system32\inetsrv\config.
Author: Thomas Pött Managing Consultant Microsoft UC
The Windows Process Activation Service encountered an error trying to read configuration data from file ‘\\?\C:\Windows\system32\inetsrv\config\applicationHost.config’, line number ’0′. The error message is: ‘Configuration file is not well-formed XML’. The data field contains the error number.
The only thing you have to do is:
copy a "healthy" applicationHost.config file in c:\inetpub\history and put it into c:\windows\system32\inetsrv\config.
Author: Thomas Pött Managing Consultant Microsoft UC
Monday, March 4, 2013
Lync 2013 Cumulative Update (CU1) and Ressources
Beside some Client Updates also the Server components are updated and some issues were addressed.
Caution:
if you are updating the Lync 2013 Server installation and you have Database Mirroring installed, you need to break the mirror and initiate the update, afterwards you have to reestablish the mirror again:
Get-CsDatabaseMirrorState -PoolFqdn Pool.FQDN -Verbose
Uninstall-CsMirrorDatabase -DatabaseType Application -SqlServerFQDN EEBE.FQDN -SqlInstanceName SQLInstanceName -DropExistingDatabasesOnMirror -Verbose
Install-CsDatabase -ConfiguredDatabases -SqlServerFqdn EEBE.Fqdn -Ver
Install-CsMirrorDatabase -DatabaseType Application -SqlServerFQDN EEBE.Fqdn -SqlInstanceName SQLInstanceName -FileShare MirrorFileshare -Verbose
Get-CsDatabaseMirrorState -PoolFqdn Pool.FQDN -Verbose
Cumulative Updates & Administrative Tools
Lync Server 2013, February 2013 CU1
Lync Server 2013 Resource Kit Tools
Lync Server 2013 Debugging Tools
Lync Server 2013 Whiteboard Archiving Viewer
Lync Server 2013 Persistent Chat Resource Kit
Development & Exchange/ SharePoint Add-On
Unified Communications Managed API (UCMA) 4.0
Designing & Planning Tools
Lync Server 2013 Planning Tool
Lync Server 2013 Capacity Calculator
Lync Connectivity Analyzer – 32-bit & 64-bit
Author: Thomas Pött Managing Consultant Microsoft UC
Caution:
if you are updating the Lync 2013 Server installation and you have Database Mirroring installed, you need to break the mirror and initiate the update, afterwards you have to reestablish the mirror again:
Get-CsDatabaseMirrorState -PoolFqdn Pool.FQDN -Verbose
Uninstall-CsMirrorDatabase -DatabaseType Application -SqlServerFQDN EEBE.FQDN -SqlInstanceName SQLInstanceName -DropExistingDatabasesOnMirror -Verbose
Install-CsDatabase -ConfiguredDatabases -SqlServerFqdn EEBE.Fqdn -Ver
Install-CsMirrorDatabase -DatabaseType Application -SqlServerFQDN EEBE.Fqdn -SqlInstanceName SQLInstanceName -FileShare MirrorFileshare -Verbose
Get-CsDatabaseMirrorState -PoolFqdn Pool.FQDN -Verbose
Cumulative Updates & Administrative Tools
Lync Server 2013, February 2013 CU1
Lync Server 2013 Resource Kit Tools
Lync Server 2013 Debugging Tools
Lync Server 2013 Whiteboard Archiving Viewer
Lync Server 2013 Persistent Chat Resource Kit
Development & Exchange/ SharePoint Add-On
Unified Communications Managed API (UCMA) 4.0
Designing & Planning Tools
Lync Server 2013 Planning Tool
Lync Server 2013 Capacity Calculator
Lync Connectivity Analyzer – 32-bit & 64-bit
Author: Thomas Pött Managing Consultant Microsoft UC
Tuesday, February 26, 2013
Lync 2013 Client CU1 released
Just for some clarification:
You need to identify your download package, depending which version you have installed.
Download the x86 package now.
Download the x64 package now.
Download the x86 package now.
Download the x64 package now.
Author: Thomas Pött Managing Consultant Microsoft UC
You need to identify your download package, depending which version you have installed.
How to obtain and install the update
The following files are available for download from the Microsoft Download Center:Lyncloc (THIS MEANS: LYNC 2013 BASIC CLIENT - downloadable version)
Download the x86 package now.Download the x64 package now.Msores (THIS MEANS: LYNC 2013 FULL CLIENT with OFFICE 2013)
Download the x86 package now.Download the x64 package now.Author: Thomas Pött Managing Consultant Microsoft UC
Thursday, February 21, 2013
Lync Mobile Client 2013 VoIP announcement
I'm so excited,
finally Microsoft did it, as I had announced last November 2012.
The VoIP feature for Lync 2013 Mobile Client and it is amazing guys....
First let me summarize some requirements:
What else is expected?
The RELEASE DATE is addressed for:
Some more, Microsoft announced:
http://www.lyncconf.com/media.aspx
Author: Thomas Pött Managing Consultant Microsoft UC
finally Microsoft did it, as I had announced last November 2012.
The VoIP feature for Lync 2013 Mobile Client and it is amazing guys....
First let me summarize some requirements:
- You will need an Lync 2013 Server CU update. CU1, which will be released soon.
- Sure, as it was with Lync 2010, you need to deploy the mobile connectivity setup up.
- You mobile device must be connected via 3G, 4G or Wifi.
What else is expected?
The RELEASE DATE is addressed for:
- Windows Phone and iPhone/ iPAD: early March 2013
- Android Phone: around April 2013
- Blackberry: on the road map
PRESENCE and IM
|
Windows
8 & Windows RT
|
Windows
Phone
|
Android
|
iPhone
|
iPAD
|
Lync and Lync online connectivity
|
YES
|
YES
|
YES
|
YES
|
YES
|
New UI, photo, status, presence
|
YES
|
YES
|
YES
|
YES
|
YES
|
View Lync contact list
|
YES
|
YES
|
YES
|
YES
|
YES
|
IM, multiparty conversations
|
YES
|
YES
|
YES
|
YES
|
YES
|
Distribution list expansion
|
YES
|
YES
|
YES
|
YES
|
YES
|
Some more, Microsoft announced:
- Battery Usage during the testing's where excellent even on IOS
- Lync Mobile Client will support call-via-work with VoIP
- Microsoft will make use of their own push service for Apple devices
- Blackberry is on the roadmap, without a dedicated timeline
- Desktop and Application Sharing is on the roadmap for all major smartphones
- the mobile client will have an feature to control where Wifi is required for Voice/ Video (good news, so high roaming costs can be controlled)
- Android Tables on the roadmap
- The Lync Server Admin Console support controlling mobile experiences for:
- Require Wifi for VoIP and Video
- Limit data usage
- push notification blocking
- Save History can be disabled
- Video federation for Lync / Skype
- Interoperability between Lync and video telepresence devices
http://www.lyncconf.com/media.aspx
Author: Thomas Pött Managing Consultant Microsoft UC
Lync 2013 Licensing Guide - How to licence Lync Server and Client
http://lync.microsoft.com/en-us/get-lync/Pages/lync-licensing.aspx
I receive, especially from Pre-Sales Consultant and Account Manager (Sales), all kind of questions regarding "How do I have to license the Lync" in different scenarios.
It is simply done like this, since we only have 4 different type of licenses:
Server Licenses:
Available for Frontend Service only (no more Standard or Enterprise License)
Client Access Licenses (CALs):
User Subscription Licenses (USLs):
Client License:
Back to several deployment scenarios for Server Licensing only!
Since the client licensing depends on when, where and which feature a user have to use.
(one upcoming change should be consider for CALs, if a user should ONLY be invited a Lync Online Conference and he will not participate in Enterprise Voice, he only needs Standard User CAL)
Example A:
700 User, no HA.
1x Standard Edition Server
1x Edge Server
2x Mediation Server, one with SIP Trunk, the other with PRI Gateway
4x SBS
License needed: 1x Lync Server (for 2010, 1x Standard Server)
Example B:
5600 User, pre - HA.
1x Enterprise Edition Server
1x Backend Server (SQL)
1x Director Server
1x Edge Server
2x Mediation Server, one with SIP Trunk, the other with PRI Gateway
10x SBS/ SBA
License needed: 1x Lync Server (for 2010: 1x Enterprise Server)+ 1x SQL Standard Server per CPU
Example C:
12000 User, HA.
2x Standard Edition Server (Frontend for Branches)
6x Enterprise Edition Server (2x3 Frontend for Site Resiliency)
4x Edge Server
3x Mediation Server, two with SIP Trunk, the other with PRI Gateway
50x SBS/ SBA
1x Monitoring
2x Persistent Chat Frontend Server
2x Persistent Chat Store (SQL)
1x Persistent Chat Compliance Store (SQL)
License needed: 8x Lync Server (for 2010: 2x Standard Edition Server, 6x Enterprise Edition Server,- Persistent Chat was not available), 4x SQL Standard Server (per CPU)
Well, let me explain the last scenario:
We have in sum 2x Standard Edition Server (frontend) and in two datacenter 3 Enterprise Edition Server each, as well the Persistent Chat Server 2x times. this requires also since it is an Frontend Server a dedicated license.
SQL follows the SQL Licensing Guidelines, but for Mirroring Feature, needed for HA, we must deploy SQL Enterprise, there for I can host other databases e.g. Monitoring also on the same SQL instance.
Hope this will help you.
Here you can compare the SQL Version:
http://www.microsoft.com/en-us/sqlserver/get-sql-server/how-to-buy.aspx
Author: Thomas Pött Managing Consultant Microsoft UC
I receive, especially from Pre-Sales Consultant and Account Manager (Sales), all kind of questions regarding "How do I have to license the Lync" in different scenarios.
It is simply done like this, since we only have 4 different type of licenses:
Server Licenses:
Available for Frontend Service only (no more Standard or Enterprise License)
Client Access Licenses (CALs):
Three CALs are available
- Lync Standard CAL (IM, presence),
- Lync Enterprise CAL (audio, video, web conferencing),
- Lync Plus CAL (Enterprise voice features)Enterprise CALs and Plus CALs are additive to the Standard CAL.CALs are available as either Device CALs or User CALs.
User Subscription Licenses (USLs):
Three USLs are associated
with Office 365 and Lync Online.
- Plan 1-provides Presence, IM, peer-to-peer VoIP and Video,
- Plan 2 adds Lync Meetings capability,
- Plan 3 adds PSTN Access (US and UK), USLs are per user only.
Client License:
- Lync 2013 client licensed via Office Professional Plus (and is also available as a standalone).
- Lync Windows 8 client is licensed via Windows Store (FREE)
- Other mobile clients are available via the relevant platform store. (FREE)
- Lync Basic 2013 client licensed via download from Microsoft. (FREE)
Back to several deployment scenarios for Server Licensing only!
Since the client licensing depends on when, where and which feature a user have to use.
(one upcoming change should be consider for CALs, if a user should ONLY be invited a Lync Online Conference and he will not participate in Enterprise Voice, he only needs Standard User CAL)
Example A:
700 User, no HA.
1x Standard Edition Server
1x Edge Server
2x Mediation Server, one with SIP Trunk, the other with PRI Gateway
4x SBS
License needed: 1x Lync Server (for 2010, 1x Standard Server)
Example B:
5600 User, pre - HA.
1x Enterprise Edition Server
1x Backend Server (SQL)
1x Director Server
1x Edge Server
2x Mediation Server, one with SIP Trunk, the other with PRI Gateway
10x SBS/ SBA
License needed: 1x Lync Server (for 2010: 1x Enterprise Server)+ 1x SQL Standard Server per CPU
Example C:
12000 User, HA.
2x Standard Edition Server (Frontend for Branches)
6x Enterprise Edition Server (2x3 Frontend for Site Resiliency)
4x Edge Server
3x Mediation Server, two with SIP Trunk, the other with PRI Gateway
50x SBS/ SBA
1x Monitoring
2x Persistent Chat Frontend Server
2x Persistent Chat Store (SQL)
1x Persistent Chat Compliance Store (SQL)
License needed: 8x Lync Server (for 2010: 2x Standard Edition Server, 6x Enterprise Edition Server,- Persistent Chat was not available), 4x SQL Standard Server (per CPU)
Well, let me explain the last scenario:
We have in sum 2x Standard Edition Server (frontend) and in two datacenter 3 Enterprise Edition Server each, as well the Persistent Chat Server 2x times. this requires also since it is an Frontend Server a dedicated license.
SQL follows the SQL Licensing Guidelines, but for Mirroring Feature, needed for HA, we must deploy SQL Enterprise, there for I can host other databases e.g. Monitoring also on the same SQL instance.
Hope this will help you.
Here you can compare the SQL Version:
http://www.microsoft.com/en-us/sqlserver/get-sql-server/how-to-buy.aspx
Author: Thomas Pött Managing Consultant Microsoft UC
How determine - LCS, OCS and LYNC Build (Version number)
Often we have the some need identifying the version number or build number for any server type Unified Communication from Microsoft has.
LCS and OCS:
For LCS or OCS, check the following key:HKLM\Software\Microsoft\Real-Time Communications\{92AC8981-AAD9-4391-8563-92E558EEF4C6}
For OCS 2007 R2, check the following key:HKLM\Software\Microsoft\Real-Time Communications\{A593FD00-64F1-4288-A6F4-E699ED9DCA35}
Version LCS/ OCS/ OCS R2
2.0.5369.0 - Live Communications Server 2005 RTM
2.0.5470.0 - Live Communications Server 2005 SP1
3.0.6362.0 - Office Communications Server 2007 RTM
3.5.6907.0 - Office Communications Server 2007 R2 RTM
Lync 2010 and Lync 2013,
we can make use of the WMI feature and have to run the following PowerShell command:
Get-WmiObject -query 'select * from win32_product' | where {$_.name -like "Microsoft Lync Server*"} | foreach {$_}
else
Get-CsServerVersion
Lync 2010
Lync 2013
RTM version number is 5.0.8308.0.
Author: Thomas Pött Managing Consultant Microsoft UC
LCS and OCS:
For LCS or OCS, check the following key:HKLM\Software\Microsoft\Real-Time Communications\{92AC8981-AAD9-4391-8563-92E558EEF4C6}
For OCS 2007 R2, check the following key:HKLM\Software\Microsoft\Real-Time Communications\{A593FD00-64F1-4288-A6F4-E699ED9DCA35}
Possible Values:
Version LCS/ OCS/ OCS R2
2.0.5369.0 - Live Communications Server 2005 RTM
2.0.5470.0 - Live Communications Server 2005 SP1
3.0.6362.0 - Office Communications Server 2007 RTM
3.5.6907.0 - Office Communications Server 2007 R2 RTM
Lync 2010 and Lync 2013,
we can make use of the WMI feature and have to run the following PowerShell command:
Get-WmiObject -query 'select * from win32_product' | where {$_.name -like "Microsoft Lync Server*"} | foreach {$_}
else
Get-CsServerVersion
Lync 2010
Version
|
Release Month, Year
|
Link to KB Article
|
Notes
|
4.0.7577.0108
|
January, 2011
|
CU 1
| |
4.0.4577.0253
|
April, 2011
|
CU 2
| |
4.0.7577.0314
|
July, 2011
|
CU 3
| |
4.0.7577.0330
|
September, 2011
|
CU 3 HF
| |
4.0.7577.0336
|
October, 2011
|
CU 3 HF
| |
4.0.7577.4051
|
November, 2011
|
CU 4
| |
4.0.7577.4053
|
November, 2011
|
CU 4 HF
| |
4.0.7577.4061
|
January, 2012
|
CU 4 HF
| |
4.0.7577.4064
|
February, 2012
|
CU 4 HF
| |
4.0.7577.4072
|
February, 2012
|
CU 5
| |
4.0.7577.4087
|
March, 2012
|
CU 5 HF
| |
4.0.7577.4098
|
June, 2012
| Security | |
4.0.7577.4103
|
June, 2012
|
CU 6
| |
4.0.7577.4109
|
October, 2012
| Security | |
4.0.7577.4356
|
October, 2012
|
CU 7
| |
4.0.7577.4374
|
January, 2013
|
CU
|
Lync 2013
RTM version number is 5.0.8308.0.
Author: Thomas Pött Managing Consultant Microsoft UC
Friday, February 15, 2013
Demystify Lync Enterprise Voice Phone Numbers and Extension
Demystify
Lync Enterprise Voice Phone Numbers and Extension
Valid Phone
Numbers based on RFC 3966
Lync Server 2013 and his related earlier products (Lync 2010 and
OCS) fully depend and follow the given requirements of RFC 3966
With this, we know what the goals are we need to fulfill, in a short sentence, we need to get all numbers translated to an E.164 format. Simply said, E.164 represent an international number format, including the “+” sign at beginning.
With this, we know what the goals are we need to fulfill, in a short sentence, we need to get all numbers translated to an E.164 format. Simply said, E.164 represent an international number format, including the “+” sign at beginning.
Example
E.164 Phone Numbers:
+498912345678 (e.g. Munich, Germany)
+6038383123 (e.g. Kuala Lumpur, Malaysia)
E.164 number a unique worldwide, therefor they are capable addressing a
single connection point.
As we understood now, it is important to follow this requirements.
Nevertheless, there are non-compliance changes local telephone companies apply.
This we need to keep in mind, while we do planning’s for our Lync international
connection points (Lync to PSTN handover, telephone providers or internal PBX).
Those specific gateway configuration I will discuss in other blog articles.
Especially, if you are having PBX systems, there are a lot of uncertainties to
consider. So better be familiar with the ISDN Protocol, and make yourself fully
capable reading and understanding this communication.
The
following are valid RFC 3966 TEL URI examples:
- tel:+4980619089123;ext=123 : the extension is part of the phone number.
- tel:+60383830160;ext=123 : the extension is not part of the phone number.
- tel:123;phone-context=HeadQuater. Never put a “+” in front!! (internal “extension” only)
Staying alive in Lync Server Enterprise Voice Deployment, keep in mind,
Lync is a fully integrated Active Directory Application, therefor it’s
necessary to ensure biunique phone
numbers. Which means in other words, only one unique phone number per user
each.
Valid Caller ID’s
A Caller ID is the Calling Party number displayed at the Called Party site. In other words, the
phone number visible at the point, where call will be received.
E.g. if Bernd (Calling Party: +49891234567) is calling Peter (Called Party
ID+603831234567), Bernd’s number will be displayed on Bernd’s Lync Client or
normal PSTN based phone.
As given in the examples of valid and RFC conform TEL URI’s, we remember
about the phone-context based numbers. If a user assigned with this format is
allowed making outside calls, you will properly display the wrong and
un-callable phone number for any PSTN/ PBX based user.
Warning:
If you consider this phone number design, be aware about all the hassle you
produce and how much effort you have to put into trouble shooting.
If you have chosen this format, truly you are able to configure other
translation rules based on the gateway capability and make this design look
nice. But it still has two sides, the outgoing call and also the incoming call,
so how are you going to translate the provide Calling Party ID???
Others you have to consider in your design and planning, please keep you
design decision consistent, so do not start mixing TEL URI formats!
Let demystify DID/ DDI (Direct
inward Dialing, sometime also called Direct Dial-In) and Extensions.
I know is sometimes very confusing, you also see people’s business cards
with several different number formats. Mostly this number formats are given
wrongly and do not make your live easy.
We keep in mind, we have probably two different scenarios how make calls:
- We have to call an Auto Attendant/ Receptionist because a Called Party has no DID. He mostly has an EXTENSION, the AA or Receptionist is able to forward this call
example: tel:+49806190890;ext=123 - The DID is known and the Calling Party is able to directly call the Called Party
example: tel:+4980619089123 or tel:+4980619089123;ext=123
Some possible advantage are, if you have for
example a Call Center, you don’t want the Agent DID presented, than you will
have to choose the Extension way in presenting a valid E.164 number to the
Called Party.
A useful Mixed Scenario:
If might be, you want to have a mixed scenario,
where the users have DID assigned, but you want to ensure only the Main Desk Number
(Receptionist/ AutoAttendant) should be presented, you are able to modify the
Lync Voice Route and enable the SUPPRESS CALLER ID feature. Than for all
outgoing calls, only and only this number is presented.
On more possible way is using Response Groups,
here any Agent can make also call on behalf! I will once in a while also write
more about RGS in Lync 2013.
As a best practice make sure to
always provide a caller ID that can be called back when calling outside the
enterprise. Specify a Line URI that contains a DID number.
Exchange Auto
Attendant
Generally I’m taking about extension, Exchange Unified
Messaging also make use of a Dial-Plan, called UM Dial Plan, a UM Dialpan
establish as link from the telephone extension number of a user, who is enabled
for Voice Mail with its associated UM-enabled mailbox. Therefor it’s another
point where the extensions will play its role. To make Lync and Exchange work
together, where Lync plays its role as seen from Exchange as a PBX. Which
relates to an extension required from each UM-enabled Mailbox. Within this Dial-Plan, you have to define the extension digit length,
properly matching the Lync assigned extension
patterns. This is not a must, but best practice.
Why? If a call will be received
by the Exchange AA and the caller want’s to connect his call to the user who is
hosted on Lync, he needs to know his extension, if now he is aware only about
the extension in Lync, he will not be able to redirect to this user. Sure, you
could make use of the speech enabled features, but what’s happened if you can’t
pronounce his name correctly?
In Exchange Auto Attendant Setup, you have the PilotIdentifierList, this list contains
the extension the AA is responsible for. Via the CAS Server, where incoming
call is identified it will be redirected to the Mailbox Server. (Exchange
2013).
In Exchange Dial-Plans, the URIType, NumberofDigitsInExtension
and the VoIP connection security will be defined. Lync and Exchange interact
with a SIP based Dial-Plan, but need its interfering extension and Phone
Number.
As I have spoken about the DID and non-DID deployments,
if the AA should be the general point of connection (Receptionist), in non-DID
deployment, need to consider the next information:
Say as an example, we have a base number defined
as: tel:+49806190890 the AA would not has an
assigned unique number. Therefor it is necessary to do some amendments.
You need to define the EXT
attribute like this: tel:+49806190890;ext=1 once this
is assigned, the RNL (Reverse Number Lookup) can work. Next would be the
associated normalization for inbound calls to the AA.
So you need a normalization rule: ^(\+49806190890)$ -> $1;ext=1
We still have the second possibility, which is
with assigned DIDs. This is straight forward as usual, so simply assign the AA:
tel:+4980619089123;ext=123
Phone Number
Extensions
As I described in the first chapter, phone numbers in Lync are based on
RFC3966, this provide us with a guideline how extension will work and must be
correctly assigned.
As in common scenarios we can have multiple customer scenarios based on historical/
classic telephony environments. Which leads us to three typical deployments:
- Classic DID based deployment
- DID based deployment in conjunction with extensions
- Deployment with internal extensions only
Regarding Lync, generally we must have extensions for several reasons,
e.g. Dail-In Conferencing as and for authenticated users, as well as simplified
login to UC Phones. If we do not provide any extensions, e.g. on an UC Phone,
the user must use is full length assigned phone number.
As we remember, extension are necessary and making feel user more
comfortable with Lync-
While you are migrating to Lync from a classic PBX system, you need to
evaluate one of this typical Phone Number Assignment. It might here be
necessary to change a number plan once after you finalized the migration. But
remember it depends on the customer’s solution you have proposed and the
technical supportability of your idea.
Lync 2013 has a new feature, which also leads you into some deployment
discussion regarding phone number assignments. You are able to bridge e.g.
PSTN-Lync-PBX or PBS-Lync-PBX.
This feature is called: Trunk & Route
Management
Continue from here; in
Lync, the phone number extension is identified with the EXT parameter.
It is not anything
with is submitted in the SIP Call initiation, but in dialing and conferencing
behaviors.
We need have a closer
look into the SIP definition of its parameters (RFC3966*):
For mandatory additional parameters (section 5.4) and the 'phone-context' and 'extension' parameters defined in this
document, the 'phone-context' parameter value is compared as a host name if it
is a 'domainname' or digit by digit if it is 'global-number-digits'. The latter is compared after removing all
'visual-separator' characters
Two types of phone
numbers can exist, either a “local-number” or a “global-number”, whereby the
type for global-numbers MUST contain a “+” sign in front.
This is not the only
difference we need to know, far more for any type of “local-number” we have an
additional mandatory parameter: “phone-context”. The “phone-context” could be compared as a “domain name”, or
identifier. Take care that all and everything in SIP URIs is case sensitive, so too the phone-context. Best practice is: use always lower case characters!
Other to consider are the included hyphens
“-“, which are allowed in SIP URIs. It makes it for humans more easily
readable. (I personally don’t like
hyphens in Lync deployments!)
Coming back to the
phone numbers itself. As we identified the “ext” (“extension”) and “phone-context” parameter, the EXT is quite
clear and understandable. It reflects the users internal phone extension,
either in the DID or non-DID deployments. BUT the phone number must be in
“global-number” format including the “+”
sign.
More complex and in
SIP URIs are the “local-number”, which goes
along with the “phone-context” parameter. I
repeat; it is the “domain name”, it is nothing usual in Lync deployments, but
if you integrate Cisco CUCM or other SIP based telephony system, you might step
over it. This parameter is define as a string too, same as the entire URI, due
to is has no numeric characters. As a possibility, the phone-context is allowed
to carry any “number” starting with a “+” sign, which is than associated as a
phone prefix, like “+49-89-4444”. It will e.g. identify the global area in
within the local-number assignment. As said this parameter is mandatory!
Simple example is:
global-number = tel:+49894444123
next example describes a hybrid DID with non-DID compliant extension
Lync Conferencing
Dial-In behaviors
First and important
for you to understand is, it is not possible to connect to a conference without
any valid Conferencing ID. If you would try to connect to the simple URL, say
meet.company.com, you will see an error taking about you have used a wrong URL.
This is an expected behavior due to security reason. It is different if you use
the Dial-In into the Conferencing Main
Number:
If you dial into the
conferencing number, regardless which region you chose, you will be prompted
for a Numeric Conferencing ID. This
ID is the reverse lookup if a valid conference is active or not.
Second here is, after
you are permitted into the Conference
General Room, it’s time to authenticate. Here we have two possibilities,
either you are joining as a guest or you join as a corporate
user. The difference is when you are a corporate user, you have several
controlling options more. But this is not what we want to discuss here in the
Enterprise Voice Extension discussion ;)
How it’s now possible
for a corporate user to identify himself to a conference?
The optimal way here
is the user’s extension and PIN. This is one of the reasons why we need to plan
for Lync based phone number extensions. Truly the full phone number will work
to, but if you assigned only non-DID number, you will definitely need an
extension number as well.
I simplified the
Dial-In behavior, since is not relevant to our scenario where we discuss about
phone number extension.
If you are joining the
conference with an authenticated Lync Client, via the Conference URL or your
Mobile Phone, the process is different because this will do the Conferencing ID
validation check automatically.
Lync Phone
Edition behaviors
Microsoft has defined
how a Lync compatible UC Phone should technically look like. Principally, a UC
Phone first has to connect to the network, which is generally configured in
DHCP (Check my Blog here), after the connection process (Device Connection Process) was successful, a user is able to login into
the UC Phone.
Here is where the Lync
Phone Number Extension comes into place, because the user has the need for
authentication as well. Since a UC Phone do not provide the normal, well-known
Domain\UserAccount login, we need another identifier. This identifier, which
must be unique, can only be the users Phone Number Extension and a dedicated,
secret PIN (Personal Identification Number).
Well here we are again
and back for the need of our assigned extensions.
Let’s make an example:
With the first
example, the user is able to login at the UC Phone, due to the user
extension=123, followed by his PIN.
Set-CsWebServiceConfiguration
-Identity Global -UsePinAuth $true
Set-CsClientPin
-Identity "company\user" -Pin 18723834
Alternatively you can
use another command sending a Welcome Email:
Set-CsPinSendCAWelcomeMail -UserUri user@company.com -From conferencing@contoso.com
With the option –TemplatePath, you can use the
CAWelcomeEmailTemplate.html
which you can modify as your company requirements are.
ISDN Protocol and
Gateway based normalization (Called Party vs. Calling Party) and Caller ID
Last but not least, I
believe it’s the right place to talk about adjustments you have to make for
Lync and the PSTN/PBX connections. First which is mostly confusing are the
different terminology Lync carries vs. PSTN (Telephony world).
Generally in each call
are logically only two parties involved. The one who is initiating the call and
the other party receiving the call. This is always the same, in Lync, at PSTN
or the PBX. The direction is also fixed, it is seen from where the call is
initiated.
Calling Party (ME – from whom), in
Lync Voice Routes also
named in (Caller
ID)
in SIP messages it’s called From:
and
Called Party (YOU – to whom)
in SIP messages it’s called To:
If we analyze the Lync
initiated call to a phone number, we have to have a look into the SIP INVITE
message:
Start-Line: INVITE sip:+ 492324554746@company.de;user=phone
SIP/2.0
From: <sip:thomas.poett@company.de>;tag=4bdaa6a338;epid=fe5337abb5
To: <sip:+492324554746@acp.de;user=phone>
Analog to Lync, we
need to have a look into the ISDN related message:
callp: mux_isdn:0 (1) ISDN[1](1756): APP : 11 calling_name ="P�Thomas"-->"Pött Thomas"
callp: mux_isdn:0 (1) ISDN[1](1756): APP : 0
called_name =""-->""
callp: mux_isdn:0 (1) ISDN[1](1756) <== ISDNCMD::CCA_RELEASE_CONF;0049806190891234;;15000492324554746;;CCAPI_CIP_ANALOG_SPEECH;1.a/B19/S2M/2xG704IDT_E1;0;0;8;19;510;1;Pött
Thomas;;0;;
callp: mux_isdn:0 (1) ISDN[1](1756) <==
ISDNMSG:
event=CCA_RELEASE_CONF
callp: mux_isdn:0 (1) ISDN[1](1756) <== ISDNMSG:callingPartyNumber1=0049806190891234
callp: mux_isdn:0 (1) ISDN[1](1756) <==
ISDNMSG:callingPartyNumber2=
callp: mux_isdn:0 (1) ISDN[1](1756) <==
ISDNMSG: calledPartyNumber=15000492324554746
callp: mux_isdn:0 (1) ISDN[1](1756) <==
ISDNMSG: redirectingNumber=
callp: mux_isdn:0 (1) ISDN[1](1756) <==
ISDNMSG:
cip=CCAPI_CIP_ANALOG_SPEECH
callp: mux_isdn:0 (1) ISDN[1](1756) <==
ISDNMSG: bChannelInterface=1.a/B19/S2M/2xG704IDT_E1
callp: mux_isdn:0 (1) ISDN[1](1756) <==
ISDNMSG: error=0
callp: mux_isdn:0 (1) ISDN[1](1756) <==
ISDNMSG: cause=0
callp: mux_isdn:0 (1) ISDN[1](1756) <==
ISDNMSG: pi=8
callp: mux_isdn:0 (1) ISDN[1](1756) <==
ISDNMSG: bChannel=19
callp: mux_isdn:0 (1) ISDN[1](1756) <==
ISDNMSG: ChannelId=510
callp: mux_isdn:0 (1) ISDN[1](1756) <==
ISDNMSG: CallControlId=1
callp: mux_isdn:0 (1) ISDN[1](1756) <==
ISDNMSG: callingName=
callp: mux_isdn:0 (1) ISDN[1](1756) <==
ISDNMSG: calledName=
callp: mux_isdn:0 (1) ISDN[1](1756) <==
ISDNMSG: ulaw=0
callp: mux_isdn:0 (1) ISDN[1](1756) <==
ISDNMSG: userToUser=
callp: mux_isdn:0 (1) ISDN[1](1756) <==
ISDNMSG: charge=
callp: CCA_RELEASE_CONF
Remember:
If you are connected to SIP
Trunk Provider, it’s the same as Lync is initiating a call, due to it’s still
SIP.
Let’s now have a look
how the ISDN -> LYNC Call works:
INVITE sip:+ 492324554746@172.28.11.222:5068;transport=tcp SIP/2.0
FROM: "+4917221711145"
<sip:+4912221711145@172.28.11.223:5066>;tag=5502-1360660857
TO: "+492324554746" <sip:+ 492324554746@172.28.11.222>
Analog to Lync, we
need to have a look into the ISDN related message:
callp: mux_isdn:0 (1)
ISDN[1](1756) ==> ISDNCMD::CCA_RELEASE_RESP;012221711145;;7946#;746;CCAPI_CIP_ANALOG_SPEECH;1.a/B30/S2M/2xG704IDT_E1;0;0;0;30;5538;1;;;0;;;
callp: mux_isdn:0 (1) ISDN[1](1756) ==>
ISDNMSG: event=CCA_RELEASE_RESP
callp: mux_isdn:0 (1) ISDN[1](1756) ==>
ISDNMSG:callingPartyNumber1=012221711145
callp: mux_isdn:0 (1) ISDN[1](1756) ==>
ISDNMSG:callingPartyNumber2=
callp: mux_isdn:0 (1) ISDN[1](1756) ==> ISDNMSG: calledPartyNumber=7946#
callp: mux_isdn:0 (1) ISDN[1](1756)
==> ISDNMSG: redirectingNumber=746
callp: mux_isdn:0 (1) ISDN[1](1756) ==>
ISDNMSG:
cip=CCAPI_CIP_ANALOG_SPEECH
callp: mux_isdn:0 (1) ISDN[1](1756) ==>
ISDNMSG: bChannelInterface=1.a/B30/S2M/2xG704IDT_E1
callp: mux_isdn:0 (1) ISDN[1](1756) ==>
ISDNMSG: error=0
callp: mux_isdn:0 (1) ISDN[1](1756) ==>
ISDNMSG: cause=0
callp: mux_isdn:0 (1) ISDN[1](1756) ==>
ISDNMSG: pi=0
callp: mux_isdn:0 (1) ISDN[1](1756) ==>
ISDNMSG: bChannel=30
callp: mux_isdn:0 (1) ISDN[1](1756) ==>
ISDNMSG: ChannelId=5538
callp: mux_isdn:0 (1) ISDN[1](1756) ==>
ISDNMSG: CallControlId=1
callp: mux_isdn:0 (1) ISDN[1](1756) ==>
ISDNMSG: callingName=
callp: mux_isdn:0 (1) ISDN[1](1756) ==>
ISDNMSG: calledName=
callp: mux_isdn:0 (1) ISDN[1](1756) ==>
ISDNMSG: ulaw=0
callp: mux_isdn:0 (1) ISDN[1](1756) ==>
ISDNMSG: userToUser=
callp: mux_isdn:0 (1) ISDN[1](1756) ==>
ISDNMSG: charge=
callp: 344874: callp: launch: exit
Launch:24849
callp: 344874: callp: scRead(930): socket=26
ret=383
callp: 344874: callp: scRead(930): socket=26
ret=704
callp: mux_sip:0 (1) calledPartyNumber="+492324554746"
callp: mux_sip:0 (1)
callingPartyNumber="+49012221711145"
callp: mux_sip:0 (1)
task="sip_isdn:sip_isdn-5540-1360661018"
callp: mux_sip:0 (1) send to
"sip_isdn:sip_isdn-5540-1360661018"
callp: mux_sip:0 (1)
calledPartyNumber="+492324554746"
callp: mux_sip:0 (1)
callingPartyNumber="+49012221711145"
callp: mux_sip:0 (1)
task="sip_isdn:sip_isdn-5540-1360661018"
callp: mux_sip:0 (1) send to
"sip_isdn:sip_isdn-5540-1360661018"
callp: mux_sip:0 (1)
calledPartyNumber="+492324554746"
callp: mux_sip:0 (1)
callingPartyNumber="+49012221711145"
callp: mux_sip:0 (1)
task="sip_isdn:sip_isdn-5540-1360661018"
callp: mux_sip:0 (1) send to
"sip_isdn:sip_isdn-5540-1360661018"
callp: mux_isdn:0 (1) ISDN[1](1756): APP :
calling_name =""
callp: mux_isdn:0 (1) ISDN[1](1756): APP :
called_name =""
Since you now
carefully analyze both calls, you will find that the calledPartyNumber and the
callingPartyNumber
has changed. This is as described, because of the Call Direction.
Additionally in the
incoming call, I marked two lines in green, this is a specialty in this customer deployment. We have to
have a redirect (redirectingNumber)
of the incoming phone number.
What happened here is, it is a hybrid deployment where Lync exist parallel to a
PBX. On the PBX the users extension is: 746,
but in Lync the extension is: 7946.
That’s why we had to redirect the call and forwarded to the “other” calledPartyNumber.
In this deployment, users who only want to use Lync, have to forward there PBX
based desk phone to the Lync extension.
Don’t get confused here, it’s straight forward.
Nothing here works, if
you would not have defined ISDN incoming and outgoing normalization rules on
the gateway itself. (PSTN normalization)
I post our setup for ISDN
incoming calls:
I post our setup for ISDN
outgoing calls:
The outgoing
normalization rules could have been simplified, due to easier support and
understanding how the setup here was done, we have decided to do a more
granular definition instead of complex Gateway Normalization.
Other Terms and
shortcuts
Calling number delivery (CND)
Calling number identification (CNID) = calling
line identification presentation (CLIP)
Reverse Number Lookup (RNL) – number to SIP
resolution
Lync Dial Plan
Once more, Lync
Enterprise Voice need properly E.164 formatted phone numbers. As per
definition, E.164 numbers a unique worldwide. Every number is a sum of it
identifier:
+<country code> <area code> <region code> <subscriber number>
The “region code” is normally an identifier within an area, ahead of the subscriber number. Say we have the city of Munich, the area code
of Munich is: 089, now our region code
depends on the location with in the 089 area, since also suburban areas, as for
example a city call Germering have the Munich area code. E.g. this region is
identified as <842>.
Regardless of this
principals, we do not need to care about this, maybe in USA or Malaysia it’s
different, but since Europe has the phone number portability, we only care
about the <area
code>.
What Lync plays for a role in
this principals?
As we need to make
sure Lync has a proper setup for Enterprise Voice with complete E.164 numbers,
we have the principal need for a mechanism who takes care that whatever a user
is dialing it will be transformed into an E.164 number. This is where the Lync
Dial-Plan comes into the game.
The Dial-Plan a simple
table providing more or less complex normalization rules based on the users
dialing behavior.
Say a user is familiar
with, e.g. an 3-digit extension for internal user calls, but Lync only knows
the E.164 number as it should, our Dial-Plan takes care and normalize this
3-digit number into a full blown identifier. Same, if the user makes a call
with in the area where her is located in, normally, say he is based in Munich,
will only dial 44441234, our Dial-Plan will handle this and normalize the call
to +498944441234.
The is a specialty in
the Dial-Plan called “External Access Prefix”, it’s a
little bit tricky with this feature in Lync.
Generally this is to
identify and change the dialing behavior once more as it is identified as an
EXTERNAL CALL.
We know this from our
classic desk phone, where we either need to dial a “0” or “9” as a common
pattern, if we want to make an outside call to other ISDN numbers.
In Lync we have two
different devices:
- UC Phone
- Lync Client
This both clients have
different dailing behaviors, see the next chapter “off-hook/ on-hook” dialing
Especially with UC
Phones, we need to take care about this differences. For our external calls, we
need the External Access Prefix.
But what this special number or
number are doing to the Dial-Plan?
Once a user starts
dialing a number for any outside call, the Dial-Plan will capture this number
prefix and cut this number of the dialed string for the next processing steps.
External Access Prefix
- A prefix can be specified that signals an external number is being dialed
- This prefix will not need to be in the normalization rules
- Internal Extension check box in the normalization rule works with the External Access Prefix to make the below client logic work
If number dialed
begins with the prefix, then:
Client removes the
prefix. Attempts to find match among the normalization rules that are for external numbers (not marked as
internal)
If no match, client
keeps the prefix. Attempts to match all the normalization rules that are for internal numbers
If no match, client
keeps the prefix. Attempts to match all the normalization rules that are for external numbers
“Off-hook” /
“On-Hook” Dialing
Dialing behavior is much
different if you use an UC Phone. As we know quite well from other normal Desk
Phones (also from home), soon we start dialing the number sequence, the phone
starts dialing.
Let’s make an example
what happened:
Say we want to place a
call to a Munich phone number, e.g. +498984212345, as usual, if you are within
the area of Munich, you start dialing with 842xxxx, but if you for example have
internal extension starting with an 8, strange things will be happened. Soon
you dialed 842, the UC Phone will initiate the call to the internal extension,
assume we have a user in US who has the internal extension ext=842.
The Lync Client acts
totally different, because only after your dialed the entire number, you have
to press the “CALL” button.
But even before you
are able to place this call, Lync has normalized the dialed phone number as you
see in the picture below. Well, the Dial-Plan with its normalization rules have
done their work for us, since the normalization rules are downloaded into the
client.
This different
behavior is called: On-Hook/ Off-Hook dialing. With the UC Phone, you properly
dial off-hook, which means you have taken off the hook and the dial patter will
be initiated via dial-tones immediately, this is call “OFF-HOOK”.
On the Lync Client
itself, after you have finished typing the phone number and you press the call
button, which simulate/ initiates the call is called “ON-HOOK”, dialing with
the hook hanged on.
Now you can fetch this
behavior with the “External Access
Prefix”, or you fallback into the programmed dialing delays programmed into
the clients, which works like the following
- In Lync, user typically dials all desired digits then presses “call”
- Normalization rules are then processed in order to find a match.
- When dialing from a device “off-hook,” an inter-digit dialing delay is used to determine when to place the call
- 1.5 second inter-digit dialing delay
- If a matching rule is found, the number will be dialed
- 10 second final time-out
- If no matching rule is found, the dialstring is sent to the FE
- Excluding patterns from the device is not supported
(* described at Technet or the TechEd
EXL318 pptx)
Lync Voice Routes
and PSTN Usage Records
Within the Lync
Topology we have finalized the steps on how a call is placed and initiated. We
have an E.164 normalized number string which can finally being used for routing
to the associated ISDN Gateway/ Median Server, if the call was not made for any
internal recipient.
Check the over next
chapter “Call Placing Hierarchy” how, when and where the call is running
through.
Voice Routes are used
in two different scenarios:
- User associated Call Placing to Gateways
- Generic Call Routing (Session Management)
We want to identify
the User associated Call Placing only.
When you configure a
user for Enterprise Voice, there are several parameter you must take care
about. One for those is the Voice Policy, which has the necessary PSTN Usage
Record reconfigured.
While in the Voice
Policy is defined, what the call features are, it also contains the PSTN Usage
Record.
What’s all this about?
Voice Route: Contains Matching Pattern,
the PSTN Gateway, Associated PSTN Usage Record
Voice Policy: Contains Call Features,
Associated PSTN Usage Record
PSTN Usage Record: is ASSOCIATED
with -> Voice Policy and Voice
Routes
Remember:
PSTN Gateway and Mediation
Server association is only defined with in the Topology!
With this interlaced
configuration, a very granular routing and call placing behavior can be
controlled in the Enterprise Voice setup.
Let’s describe the process for an
active user with an assigned Voice Policy:
After the normalized
call will be taken care by Lync Enterprise Voice, it will be now passed through
the Voice Policy, so the Call Feature
checking can be accomplished before the routing will be initiated. Assume the
call shall be routed now, the PSTN Usage
Record comes into the game.
As the Voice Route is always associated with
the PSTN Usage Record, Lync knows
where to go with this call. It is sub-sequential how the PSTN Usage Record will processed. It starts with its first Voice Route. Within in the Voice Route, the matching pattern must
be checked and only if it fits to the dialing string it will be processed, else
the next PSTN Usage Record will be
checked until the call is placed or a “Call Could not be routed” messages
is provided back to the calling client.
We assume a matching
route was found and the next steps regarding call processing could be started.
During our Topology Design we have defined the PstnGateways/ SIP Trunk Provider
IP’s, where the call now will be handed over to. Also here are multiple Gateways possible to be addressed. It is
a round robin procedure how Lync
place the call to the gateways.
Here Lync 2013 is with
it actual version supporting M:N
Mediation Server and Gateway association. In our Voice Route, we only have to define the PstnGateway object, due to a Mediation Server is only part of the
Topology, but not involved as an object in Voice Routing!
Difference between
Lync 2010 and Lync 2013 is the naming for Associated
Gateway vs. Associated
Trunks.
This is simply said
the same in the Set-CsVoiceRoute command,
for both Lync Server Versions 2010/2013 it is the –PstnGatewayList parameter.
Lync 2013:
Lync 2010:
Lync Trunk Configuration
(applied Normalization and Translation)
Let’s understand and
talk about the Lync “Trunk Configuration”. Perhaps it
confusing for some people what the difference is between a SIP Trunk and the Trunk
Configuration. Well, this are two different kind of technology services.
Principally, truly both are Trunk related, which means in other words
Point-to-Point connections.
Just to remember, if
you have SIP Trunk, which is the Telephony Connection from Lync to a Telephony
Provider via the SIP protocol. We have the technical requirement for supported
SIP Trunk provider listed below. This are the technical connectivity settings
which you have to define in Lync Topology as it is the Media Gateway:
- Ports: TCP 5060 (TLS 5061) and UDP 60.000-64.000
- Valid Certificate if TLS is used
- G.711 a-law (used primarily outside North America)
- G.711 µ-law (used in North America)
It has nothing to do
with the definition what could and how could it be delivered to those endpoint.
Here the Trunk Configuration comes into the game,
we need a possibility to control the flow settings of those Point-to-Point
connections to PSTN Gateway, IP-PBX or SBC (Session Border Controller). As it’s
now clear, a Trunk Configuration is
the flow control setting and cannot only be used between SIP Trunk Provider and
Lync, it also can be used inside Lync Environment to control the SIP Flow to
other types of Telephony connection points.
I’m not describing how
to setup a Network Topology in Lync with Policy
Profiles, Regions, Sites, Subnets, Region Links and Site Routes, which all are required to make a Trunk Configuration work.
If all this is the
case, why I’m talk in the Phone Number Extension Blog about the Trunk Configuration.
In Trunk Configuration we can define once more Translation Rules, which will
modify the transmitted phone numbers. We need to take care and consider if and
what we have to translate on Trunk Configuration.
I will next concentrate
describing and defining the Trunk Configuration Parameter.
With Lync 2013 the
improvements regarding Enterprise Voice were driven more towards an Enterprise
capable system. Therefor it’s not surprising we see some differences in Trunk
Configurations too. I focus now only on the features visible in the Lync
Control Panel (CSCP).
Behind the bold
written parameter, L10 stands for Lync 2010 and L13 for Lync 2013.
First we need to
determine what type of Trunk
Configuration we need: Pool or Site(L10/L13)
·
Pool (Site): assigned to a Lync Site
defined in the Topology
·
Site (Service): a service, like PstnGateway object defined in the Topology
Maximum early dialog supported (L10/L13): maximum count of INVITE dialog (* see detailed description)
Encryption support level (L10/L13): (SRTPMode) – define if media traffic is
encrypted or not
Enable Media Bypass (L10/L13): define if the Mediation Server can be
bypassed by the PSTN connection point and the client
Centralized media processing (L10/L13): if the Gateway object supports an unique IP
for signaling and media traffic
Enable refer support (L10/L13): SIP REFER command support for Call Transfer
(RFC3515)
Associated Translation Rules (L10):
at this point of configurations, we are
able to modify the last time the transmitted Phone Number into a valid format
for Site or Pool (Gateway Object), e.g. a SIP Trunk Provider do not support any
E.164 format, or requires an identifier, this is the point where to configure
this last translation (in other words, similar like a normalization) – As in
Lync 2010 it is only the Calling number
Enable RTP latching (L13): This parameter will enabled Media Bypass option
for Client (RTP/ RTCP) located behind NAT or Firewall. The SBC must support
latching.
Enable forward call history (L13): Call history data can be forward to the trunk.
Enable forward P-Asserted-Identity data (L13): (P-Asserted-Identity (PAI) header can be
forwarded along the call to provide a way the caller can be identified.
Enable outbound routing failover timer (L13): If call were not answered from the associated
gateways after 10 sec, the call will be forwarded to the next available trunk,
else if no additional trunks, a call drop occurs.
Associated PSTN Usage (L13): As described while I explained the Voice
Route, PSTN Usage records are required to be configured with this Trunk too.
Associated translation rules: Translations rules modifying the outgoing call
Calling
number translation rules (L13): Will
modify the calling number (person who called)
Called
number translation rules (L13): modify
the called number (person being called)
*) See the chapter
above for detailed explanation for calling vs. called
There are many more
option which can be configured on Trunk Configuration in Lync 2013, like the
3ppc, Office 365 Online Voice, E-9-1-1 (Presence Information Data Format
Location Object : PIDF-LO) and much more. This will be part in one of my next
Blogs, when I’m talking about Deep-Inside
Enterprise Voice.
*) Early Dialogs:
RFC 3261: A dialog contains certain pieces of state needed for further message transmissions within the dialog. This state consists of the dialog ID, a local sequence number (used to order requests from the UA to its peer), a remote sequence number (used to order requests from its peer to the UA), a local URI, a remote URI, remote target, a boolean flag called "secure", and a route set, which is an ordered list of URIs. The route set is the list of servers that need to be traversed to send a request to the peer. A dialog can also be in the "early" state, which occurs when it is created with a provisional response, and then transition to the "confirmed" state when a 2xx final response arrives. For other responses, or if no response arrives at all on that dialog, the early dialog terminates.
In other words, SIP
Messages are part of a communication (dialogs), e.g. in our Trunk Configuration
negotiation about the inside protocols. We define here how many INVITES can be negotiated.
Some of the SIP Trunk Provider support less than the default setting in Lync,
we need therefor a Trunk Configuration to support the SBC requirements given to
us.
Lync 2010
Call Placing
Hierarchy and Workflow
During my demystifying
part about Phone Number Extension, I wrote a lot what extensions are, where and
how they are used. Finally it is time to present the entire Routing Process,
which means the Work Flow what it happened during an initiated Lync Call.
We differentiate
between the Dialing Behaviors, the Routing and Call
Authorization. An important part
of the process cannot be biunique identified to either one of the sites. This
is the RNL (Reverse Number Lookup), the process, where a dialed number will be
backward associated with a Voice Enabled Lync User. You can easily verify this
process by typing a number of a well-known internal Lync user. After the Dial-Plan
are were processed, the RNL does its work and have a look into Active Directory
to verify if a user’s phone number associated with an AD user. Sure it’s not
directly AD, since AD queries are too slow for Lync (VoIP), Lync did its work
much earlier and stored the User (SIP address) and Phone Number in its own
database, where the RNL will be cross-check it.
Author: Thomas Pött Managing Consultant Microsoft UC
Subscribe to:
Posts (Atom)