Tonino Filipovic

Moving Central Management Store in Disaster Recovery scenario

ToninoF — Sun, 27 Nov 2011 00:21:42 GMT

If your CMS pool is unavailable and cannot be recovered in short time or at all, you’ll have to move Central Management Store to another pool to be able to make any changes in the topology. However, you’ll also have to move all other services hosted on failed pool (Conference Directory, Users, Dial-in Access Numbers, Response Groups, etc.)

Prerequisites for successful CMS move:

- Backup of CsConfiguration

- Backup of CsLisConfiguration

- Backup of RGS configuration

- Backup of user data (dbimpexp)

To move these services follow the steps below:

A. From a user account that is a member of the RTCUniversalServerAdmins group, log on to any Front-end server in a pool to which CMS is going to be moved and open Lync Server Management Shell

B. Run the following cmdlet to install the CMS database on a target (new) pool back-end server

Install-CSDatabase -CentralManagementDatabase -SqlServerFqdn be02.contoso.com -SqlInstanceName rtc

Note: use sql server and instance names relevant to your environment

C. Run the following Management Shell cmdlet to move Central Management Store

Move-CsManagementServer -ConfigurationFileName "C:\CsConfiguration.zip" -LisConfigurationFileName "C:\CsLisConfiguration.zip" –Force

Note: use filenames relevant to your environment

Note: Move-CsManagementServer also updates the SCP to point to the new Central Management Store location.

D. Run Enable-CsTopology

E. Move Conference Directory associated with failed pool to other frontend pool by running the following Management Shell cmdlets:

Get-CsConferenceDirectory | where {$_.ServiceID -match “UserServer:FQDN_of_failed_pool”> | Move-CsConferenceDirectory -TargetPool <targetPoolFQDN> -Force

F. Move users from pool01 to target pool using either Control Panel or following Management Shell cmdlet:

Get-CsUser | where {$_.registrarpool –match “FQDN_of_old_pool”} | Move-CsUser –target “FQDN_of_new_pool” –Force

Note: Force move user will just move user accounts but will not move data associated with users (such as conferences). You’ll need to have this information exported previously (using dbimpexp on a regular basis) to be able to restore also user associated data.

G. If Simple URLs were pointing to the “old” pool, make sure to change DNS entries to point to the new pool (make sure that Meet and Dialin FQDNs are present in SAN of pool’s certificate).

H. Move RGS configuration to the new pool. Follow instructions in the procedure Restoring Response Group Settings, but make sure to import settings to the new pool.

Note: you will need to have RGS Config information exported on a regular basis (at least after every change) so you can import RGS configuration to another pool.

I. If there are Dial-In Access numbers hosted by the old pool, those should be migrated to the new pool using the following syntax:

Move-CsApplicationEndpoint -Identity <SIP URI of the access number to be moved> -TargetApplicationPool <FQDN of the pool to which the access number is moving> -Force

J. Import exported resources (users, contacts, conference directories) to a new pool using Dbimpexp tool:

- Make sure User Replicator has finished full sync. An event is logged upon completion (30024). You can trigger full sync with Update-CsUserDatabase cmdlet

- Run Dbimpexp.exe from the support folder where Communications Server is installed, using the following syntax:

For Standard Edition Server:

dbimpexp.exe /import /hrxmlfile:"c:\SavedUserData.xml" /restype:all

For an Enterprise pool:

dbimpexp.exe /import /hrxmlfile:"c:\SavedUserData.xml" /sqlserver:<sql server host name> /restype:all

Optional: If failed CMS pool also held a CAC PDP role, move this role to a new CMS pool using Topology Builder

Lync Server 2010 DR scenarios – Restoring CMS server

ToninoF — Fri, 25 Nov 2011 21:50:49 GMT

I just realized that it’s been quite a while since I announced in my last blog that I’d publish DR procedure for SQL server holding CMS (Central Management Store).

The procedure is quite similar to previous one (Restoring Enterprise Edition Back End server NOT holding CMS), with a few important differences (such as creating CMS database, for example) :

A. Start with a clean or new server that has the same fully qualified domain name (FQDN) as the failed computer and install the operating system.

B. From a user account that is a member of the RTCUniversalServerAdmins group, log on to the server you are restoring.

C. Install SQL Server 2008 R2, 2008 or SQL Server 2005 keeping the instance names the same as before the failure.

D. Start the Lync Server Management Shell on any available Front End server: Click Start, click All Programs, click Microsoft Lync Server 2010, and then click Lync Server Management Shell.

E. Recreate the Central Management store database. At the command line, type:

Install-CsDatabase –CentralManagementDatabase –SqlServerFqdn <FQDN> -SqlInstanceName <instance name> -Verbose

For example:

Install-CsDatabase –CentralManagementDatabase –SqlServerFqdn Server01.contoso.com -SqlInstanceName cms –Verbose

F. Set the Active Directory service control point for the Central Management store. At the command line, type:

Set-CsConfigurationStoreLocation –SqlServerFqdn <FQDN> -SqlInstanceName <instance name> -Verbose

For example:

Set-CsConfigurationStoreLocation –SqlServerFqdn Server01.contoso.com -SqlInstanceName cms –Verbose

G. Import the Central Management store data from $Backup. At the command line, type:

Import-CsConfiguration –FileName <CMS backup file name>

Example:

Import-CsConfiguration –FileName "C:\Config.zip"

H. Restore File store and share it

I. Publish the topology using Topology Builder (recommended method):

Start Topology Builder: Click Start, click All Programs, click Microsoft Lync Server 2010, and then click Lync Server Topology Builder.
Click Download Topology from existing deployment, and then click OK.
Select the topology, and then click Save. Click Yes to confirm your selection.
Right-click the Lync Server 2010 node, and then click Publish Topology.

J. Restore Location Information data to the Central Management store database. At the command line, type:

Import-CsLisConfiguration –FileName <LIS backup file name>

For example:

Import-CsLisConfiguration –FileName "$Backup\E911Config.zip"

K. Create required databases on BE server by running the following command:

Install-CsDatabase –configuredDatabases –SqlServerFQDN <BE_FQDN>

Note: This step also creates QoeMetrics and LcsCDR if this server hosts Monitoring databases.

L. Restore user data by performing either of the following restore procedures:

Option A:

Restore RTC database from backup using SQL Server Management Studio. (use REPLACE option when restoring)

If you’re getting error stating that exclusive access to the database could not be obtained, run the following SQL Query in SQL Server Management Studio (providing correct path to backup file):

USE Master

ALTER DATABASE rtc SET SINGLE_USER with ROLLBACK IMMEDIATE

RESTORE DATABASE rtc

FROM DISK = ‘c:\backup\rtc.bak’

WITH REPLACE

GO

Option B:

Verify that at least one Front End Server in the pool is running and that the User Replicator process has completed a full synchronization cycle. If you run Dbimpexp.exe before the synchronization is complete, the command will fail.

Important:

The Lync Server 2010 User Replicator service initial synchronization process occurs when the Lync Server 2010 Front End Server is started for the first time or when a regenerate operation is initiated.

LS User Replicator will log Event ID 30024 for completed initial synchronization of AD domain and user database.

If necessary (e.g. initial user synchronization has not been completed for any reason) you can trigger synchronization cycle by issuing Update-CsUserDatabase powershell command.

To restore the user data, at the command line, type:

Dbimpexp.exe /hrxmlfile:<path and file name of backed up Rtc database> /sqlserver:<SQL Server FQDN>\<instance name> /import /restype:all

For example:

Dbimpexp.exe /hrxmlfile:D\BackupUsers.xml /sqlserver:sql.contoso.com\rtc /import /restype:all

M. If you deployed Response Group on this pool, restore the Response Group configuration data.

From a user account that is a member of the RTCUniversalServerAdmins group (or has equivalent user rights), log on to any available Front End server.

Locate a copy of the script required for this procedure at http://blogs.technet.com/b/csps/archive/2011/02/09/scriptrgsrestore.aspx . Copy the code and paste it into a text editor, such as Notepad. Save the code as Get-CsApplicationContact.ps1.
Start the Lync Server Management Shell: Click Start, click All Programs, click Microsoft Lync Server 2010, and then click Lync Server Management Shell.
At the command line, navigate to the folder where you saved the script, and then type:

Import-Module .\Get-CsApplicationContact.ps1

To retrieve the list of Response Group contact objects that are associated with the pool, at the command line, type:

Get-CsApplicationContact –OwnerUrn "urn:application:Rgs" –Filter "(MSRTCSIP-ApplicationOptions=1)" –RegistrarPool <pool FQDN>

For example:

Get-CsApplicationContact –OwnerUrn "urn:application:Rgs" –Filter "(MSRTCSIP-ApplicationOptions=1)" –RegistrarPool "pool01.contoso.com"

Review the output of the Get-CsApplicationContact script to verify that the contact objects listed are the ones you want to remove. To remove the contact objects, at the command line, type:

Get-CsApplicationContact –OwnerUrn "urn:application:Rgs" –Filter "(MSRTCSIP-ApplicationOptions=1)" –RegistrarPool <pool FQDN> -Delete

Note:

You are prompted to confirm the deletion of each contact object, and you can skip any contact objects that you do not want to delete.

To restore the configuration settings, do the following:

a. If you have not already done so, locate the RgsImportExport.ps1 script in the Lync Server 2010 Resource Kit, and save it to the computer.

b. At the command line, navigate to the folder where you saved the script, and type:

Import-Module .\RgsImportExport.ps1
Import-CsRgsConfiguration ApplicationServer:pool01.contoso.com –FileName D:\RgsConfig_pool01.zip

N. If this Back End Server also hosts Archiving or Monitoring databases, restore the Archiving or Monitoring data by using a SQL Server management tool, such as SQL Server Management Studio (use REPLACE option when restoring databases)

IMPORTANT:

If Option A in step 13 was used to restore user data, Event IDs 32118 and 51009 could be logged in Lync Server Event log, caused by crossed databases chaining being disabled, in which case it will be needed to run the following command in SQL Query:

Alter database RTC set db_chaining on

Alter database RTCDYN set db_chaining on

Lync Server 2010 Disaster Recovery scenarios – Restoring Enterprise Edition Back end server

ToninoF — Sat, 04 Jun 2011 18:09:00 GMT

While you can find official Lync Server 2010 Backup/Restore guide at Backing Up and Restoring Lync Server 2010, in this article I’m providing an additional recovery scenario to restore the data.

There’s nothing wrong with the procedure in official online Lync documentation, but while it is focusing solely on using Dbimpexp tool to backup and restore user data, this article provides another method to restore the data stored on your failed back end server – restore RTC database using SQL Server Management Studio.

First prerequisite to use this option to recover your data is, obviously, to have a backup of RTC database which you can conduct using SQL Server Management Studio.

If you are wondering why you would look for alternative solutions when you can use Dbimpexp tool, one good reason would be to avoid dependency on User Replicator full synchronization. Namely, if you want to successfully import data using Dbimpexp tool, you need to make sure that User Replicator process has completed initial synchronization (logged as Event ID 30024).

Certainly, you can trigger full synchronization with Update-CsUserDatabase and wait for completion of initial sync (make sure Event ID 30024 is logged), but in this case you depend on existence of at least one Front end server to trigger this process. In site disaster scenarios, though (such as natural disaster, site power failure etc), where all your Front end servers might be unavailable, you’d have to first rebuild at least one Front End server to trigger User Replicator initial sync.

Long story short, it might be beneficial to have multiple options when restoring user data, and that is why I’d recommend backing up RTC database on a regular basis (apart from regular export using Dbimpexp tool), so you can pick the method that suit you best.

So without further ado, let’s jump to the procedure itself:

A. Start with a clean or new server that has the same fully qualified domain name (FQDN) and IP settings as the failed SQL Back end server.

B. From a user account that is a member of the RTCUniversalServerAdmins group, log on to the server you are restoring.

C. Install SQL Server 2008 or SQL Server 2005 (whichever was deployed on your failed server) keeping the same SQL version and Service Pack, as well as instance names as before the failure.

D. From any available Front End server in environment:

Start the Lync Server Management Shell: Click Start, click All Programs, click Microsoft Lync Server 2010, and then click Lync Server Management Shell
Use Install-CsDatabase cmdlet to create configured BE databases

Install-CsDatabase –ConfiguredDatabases –SqlServerFqdn <sqlfqdn>

Note: if the failed back end server hosted Archiving or/and Monitoring server databases, those databases will also be created when running Install-CsDatabase –ConfiguredDatabases

E. Restore the data by performing either of two options below:

Option A – Restore RTC database

a) Restore RTC database from backup using SQL Server Management Studio. (use REPLACE option when restoring database)

b) If you’re getting error stating that exclusive access to the database could not be obtained, run the following SQL Query in SQL Server Management Stuido (providing correct path to backup file):

USE Master

ALTER DATABASE rtc SET SINGLE_USER with ROLLBACK IMMEDIATE

RESTORE DATABASE rtc

FROM DISK = ‘c:\backup\rtc.bak’

WITH REPLACE

Option B – use Dbimpexp to import data to clean database

a) Verify that at least one Front End Server in the pool is running and that the User Replicator process has completed a full synchronization cycle. If you run Dbimpexp.exe before the synchronization is complete, the command will fail.

Important:

The Lync Server 2010 User Replicator service initial synchronization process occurs when the Lync Server 2010 Front End Server is started for the first time or when a regenerate operation is initiated.

LS User Replicator will log Event ID 30024 for completed initial synchronization of AD domain and user database.

If necessary (e.g. initial user synchronization has not been completed for any reason) you can trigger synchronization cycle by issuing Update-CsUserDatabase powershell command.

b) To restore the user data, at the command line, type:

Dbimpexp.exe /import /hrxmlfile:<path and file name of backed up Rtc database> /sqlserver:<SQL Server FQDN>\<instance name> /restype:all

For example:

Dbimpexp.exe /import /hrxmlfile:D\BackupUsers.xml /sqlserver:sql.contoso.com\rtc /restype:all

F. Restore RGS configuration settings

Note: to restore RGS configuration settings, you need to have a backup of RGS configuration. Please refer to Backing up Core Data and Settings for information on how to backup RGS configuration.

From a user account that is a member of the RTCUniversalServerAdmins group (or has equivalent user rights), log on to any Front End server.
Copy the Get-CsApplicationContact.ps1 script, located in the Lync Server PowerShell blog at http://go.microsoft.com/fwlink/?LinkId=210869, and paste it into a text editor, such as Notepad or a Windows PowerShell editor. Save the script as Get-CsApplicationContact.ps1 on the server.
Start the Lync Server Management Shell: Click Start, click All Programs, click Microsoft Lync Server 2010, and then click Lync Server Management Shell.
At the command line, navigate to the folder where you saved the script, and then type:

Import-Module .\Get-CsApplicationContact.ps1

To retrieve the list of Response Group contact objects that are associated with the pool, at the command line, type:

Get-CsApplicationContact –OwnerUrn "urn:application:Rgs" –Filter "(MSRTCSIP-ApplicationOptions=1)" –RegistrarPool <pool FQDN>

For example:

Get-CsApplicationContact –OwnerUrn "urn:application:Rgs" –Filter "(MSRTCSIP-ApplicationOptions=1)" –RegistrarPool "pool01.contoso.com"

Review the output of the Get-CsApplicationContact script to verify that the contact objects listed are the ones you want to remove. To remove the contact objects, at the command line, type:

Get-CsApplicationContact –OwnerUrn "urn:application:Rgs" –Filter "(MSRTCSIP-ApplicationOptions=1)" –RegistrarPool <pool FQDN> -Delete

Note: You are prompted to confirm the deletion of each contact object, and you can skip any contact objects that you do not want to delete.

To restore the configuration settings, do the following:
- If you have not already done so, locate the RgsImportExport.ps1 script in the Lync Server 2010 Resource Kit, and save it to the computer.
- Using Lync Management Shell navigate to the folder where you saved the script, and type:

Import-Module .\RgsImportExport.ps1

Import-CsRgsConfiguration ApplicationServer:pool01.contoso.com –FileName D:\RgsConfigBackupFile.zip

G. If Option A (RTC database restore) in step 5 was used to restore user data, Event IDs 32118 and 51009 could be logged in Lync Server Event log, caused by crossed databases chaining being disabled. In this case you need to run the following command in SQL Query windows:

Alter database RTC set db_chaining on

Alter database RTCDYN set db_chaining on

Summary

This article addresses recovery of your failed Enterprise Edition Back End server, providing two different methods to restore the data.

Apart from use of Dbimpexp tool to recover user data, an alternative recovery option is provided – restore of RTC database using SQL Server Management Studio.

Restore of RTC database does not depend on full synchronization of User Replicator process and is thus preferred scenario in situations when you might not have accessible Front End server to trigger User Replication sync.

RTC database restore method can be used in all situations except when it’s necessary to restore user data from one pool to another pool, in which case you’ll have to use Dbimpexp tool.

This article addresses specifically the failure of the SQL Back End server that does not host Central Management Store. That specific scenario will be addressed in my next blog.

Outbound Routing Fault Tolerance in Lync Server 2010

ToninoF — Sun, 06 Feb 2011 10:21:22 GMT

Enterprise Voice fault tolerance (as well as load balancing) is enabled in several ways in Lync Server 2010. We can start with possibility to deploy Enterprise Edition pool with multiple Front End servers (with either collocated Mediation service or deploying standalone Mediation Server pool with multiple Mediation servers). Apart from achieving fault tolerance through this redundant configuration at a pool level, outbound calls will also be effectively load balanced by configuring DNS load balancing on standalone Mediation Server Pool.

However, in case that site resiliency is required, even configuration with multiple servers in Enterprise Edition or Mediation pools in Central site will not be sufficient to address this requirement. In this case a multiple data center topology has to be deployed. More information about central site voice resiliency as a recommended approach to central site resiliency can be found in official Lync Server 2010 documentation under Planning for Central Site Voice Resiliency.

Apart from these multiple fault tolerance options being available out-of-the-box (but which, nevertheless, require correct planning), Enterprise Voice admins can further enhance voice fault tolerance by configuring Outbound Call Routing components and settings in redundant fashion. Let’s assume that Contoso has deployed multiple data center topology with Enterprise Edition pool and standalone Mediation server pool in each data center:

Outbound call routing configuration steps in Lync Server 2010 differ somewhat compared to OCS 2007 and OCS 2007 R2. While not much has changed in configuring Normalization rules, Voice Policies and PSTN Usages, the configuration of Voice Routes has changed significantly. The biggest change is that now you do not associate Routes with Mediation servers, but rather directly with Gateway peers (which can be IP/PSTN Gateway, SIP Trunk provider Session Border Controller, IP PBX).

However, prior to configuring Routes, it is necessary to associate Mediation servers with gateway peers (IP/PSTN Gateway, SBC, IP PBX) when defining your topology in Topology Builder.

What impact does this configuration have to your outbound routing?

The answer is pretty straightforward – by associating multiple gateway peers with the same route, you’re adding another layer of fault tolerance to your outbound routing. This is possible since routing now determines which gateway to use for a call and the Mediation Server associated with that gateway will handle the call. Although you could achieve similar configuration in previous OCS versions (by configuring multiple Mediation servers in the same route), the level of granularity in configuring fault tolerance on outbound routing was significantly lower. In his article my colleague Jens touches some significant changes introduced in Lync Server 2010 (no more 1:1 relationship between Mediation server and gateway, as well as load balancing the calls when having multiple gateways in the route).

Let’s see how it works using following examples:

Example A: Sunny day, all components working

Let’s suppose that Marino is hosted on EE Pool A in Data center A. He places a call to PSTN number, and the CroatiaNationalCalls route is used to carry the call. Apart from containing PSTN Usage that match those in Marino’s Voice Policy, the CroatiaNationalCalls voice route is associated with both Gateway peer A and Gateway peer B. The red intermittent line shows signaling path, while green line shows media path.

Couple of (shorten) SIP traces will show that Mediation Pool A (Mediation pool medpool.w14lab.com and mediation server w14ms01.w14lab.com) is used to handle the call:

Direction: outgoing
Peer: medpool.w14lab.com:5070
Message-Type: request
Start-Line: INVITE sip:+385351234567@172.31.255.240:5070;user=phone;maddr=medpool.w14lab.com SIP/2.0
From: "Marino Filipovic"<sip:marinof@contoso.com>;tag=fb6c460929;epid=29a361e88d
To: <sip:+385351234567@contoso.com;user=phone>
CSeq: 1 INVITE
Call-ID: f2f17de2c5ed6a1c82e01b0fb1ccf9eb
Record-Route: <sip:pool01.w14lab.com:5061;transport=tls;ms-fe=w14fe01.w14lab.com;opaque=state:T;lr>;tag=F9D9739CC4664BAAA1D425A3E6D2F5D4
Via: SIP/2.0/TLS 172.30.255.102:52633;branch=z9hG4bK78DA00AB.F7405DF5D7C1D3DA;branched=TRUE
Via: SIP/2.0/TLS 172.30.255.171:59990;ms-received-port=59990;ms-received-cid=401E00
ms-application-via: SIP;ms-urc-rs-from;ms-server=w14fe01.w14lab.com;ms-pool=pool01.w14lab.com;ms-application=ad894dc3-55e0-44bf-a07e-3c073aaa4a57
P-Asserted-Identity: "Marino Filipovic"<sip:marinof@contoso.com>,<tel:+38514802002>
ms-application-via: w14be01.w14lab.com_rtc;ms-server=w14fe01.w14lab.com;ms-pool=pool01.w14lab.com;ms-application=51FB453D-5B9F-45df-83B4-ADD1F7E604A8
Contact: <sip:marinof@contoso.com;opaque=user:epid:c0-4HR_d61GaEzW7fhYCgAAA;gruu>
User-Agent: CPE/3.5.6907.0 OCPhone/3.5.6907.0 (Office Communicator Phone 2007 R2)

Direction: incoming
Peer: medpool.w14lab.com:5070
Start-Line: SIP/2.0 183 Session Progress
From: "Marino Filipovic"<sip:marinof@contoso.com>;tag=fb6c460929;epid=29a361e88d
To: <sip:+385351234567@contoso.com;user=phone>;tag=ec42fc28ac;epid=95500EB922
CSeq: 1 INVITE
Call-ID: f2f17de2c5ed6a1c82e01b0fb1ccf9eb
VIA: SIP/2.0/TLS 172.30.255.102:52633;branch=z9hG4bK78DA00AB.F7405DF5D7C1D3DA;branched=TRUE,SIP/2.0/TLS 172.30.255.171:59990;ms-received-port=59990;ms-received-cid=401E00
RECORD-ROUTE: <sip:pool01.w14lab.com:5061;transport=tls;ms-fe=w14fe01.w14lab.com;opaque=state:T;lr>;tag=F9D9739CC4664BAAA1D425A3E6D2F5D4
CONTACT: <sip:w14ms01.w14lab.com@contoso.com;gruu;opaque=srvr:MediationServer:CxCmXfo8Z1K91JOq_lHpMgAA>;isGateway
SERVER: RTCC/4.0.0.0 MediationServer

Glossary:

pool01.w14lab.com = EE Pool A

medpool.w14lab.com = Mediation Pool A

w14ms01.w14lab.com = Mediation Server in Med. Pool A

w14fe01.w14lab.com = FE server in EE Pool A

172.31.255.240 = Gateway peer A

Example B: Mediation Pool A and/or Gateway peer A down

In case whole Mediation pool A (or Gateway peer A) is down, both signaling and media would take different path, as shown below and recorded in subsequent SIP trace:

Direction: outgoing
Peer: medpool02.w14lab.com:5070
Message-Type: request
Start-Line: INVITE sip:+385351234567@172.31.255.241:5070;user=phone;maddr=medpool02.w14lab.com SIP/2.0
From: "Marino Filipovic"<sip:marinof@contoso.com>;tag=ec7fb59bd1;epid=29a361e88d
To: <sip:+385351234567@contoso.com;user=phone>
CSeq: 1 INVITE
Call-ID: a308fa7249b5dc9c142cd0df87dfe669
Record-Route: <sip:pool01.w14lab.com:5061;transport=tls;ms-fe=w14fe01.w14lab.com;opaque=state:T;lr>;tag=F9D9739CC4664BAAA1D425A3E6D2F5D4
Via: SIP/2.0/TLS 172.30.255.102:52581;branch=z9hG4bK0A7C7979.7D6F128CBD51436D;branched=TRUE
Via: SIP/2.0/TLS 172.30.255.171:59990;ms-received-port=59990;ms-received-cid=401E00
ms-application-via: SIP;ms-urc-rs-from;ms-server=w14fe01.w14lab.com;ms-pool=pool01.w14lab.com;ms-application=ad894dc3-55e0-44bf-a07e-3c073aaa4a57
P-Asserted-Identity: "Marino Filipovic"<sip:marinof@contoso.com>,<tel:+38514802002>
ms-application-via: w14be01.w14lab.com_rtc;ms-server=w14fe01.w14lab.com;ms-pool=pool01.w14lab.com;ms-application=51FB453D-5B9F-45df-83B4-ADD1F7E604A8
Contact: <sip:marinof@contoso.com;opaque=user:epid:c0-4HR_d61GaEzW7fhYCgAAA;gruu>
User-Agent: CPE/3.5.6907.0 OCPhone/3.5.6907.0 (Office Communicator Phone 2007 R2)

Direction: incoming
Peer: medpool02.w14lab.com:5070
Message-Type: response
Start-Line: SIP/2.0 183 Session Progress
From: "Marino Filipovic"<sip:marinof@contoso.com>;tag=ec7fb59bd1;epid=29a361e88d
To: <sip:+385351234567@contoso.com;user=phone>;tag=76451dc3ba;epid=2756E7038A
CSeq: 1 INVITE
Call-ID: a308fa7249b5dc9c142cd0df87dfe669
VIA: SIP/2.0/TLS 172.30.255.102:52581;branch=z9hG4bK0A7C7979.7D6F128CBD51436D;branched=TRUE,SIP/2.0/TLS 172.30.255.171:59990;ms-received-port=59990;ms-received-cid=401E00
RECORD-ROUTE: <sip:pool01.w14lab.com:5061;transport=tls;ms-fe=w14fe01.w14lab.com;opaque=state:T;lr>;tag=F9D9739CC4664BAAA1D425A3E6D2F5D4
CONTACT: <sip:w14ms11.w14lab.com@contoso.com;gruu;opaque=srvr:MediationServer:28bAlNPmzFOn7fSHzYQ4VwAA>;isGateway
SERVER: RTCC/4.0.0.0 MediationServer

Glossary

pool01.w14lab.com = EE Pool A

medpool02.w14lab.com = Mediation Pool B

w14ms11.w14lab.com = Mediation Server in Med. Pool B

w14fe01.w14lab.com = FE server in EE Pool A

172.31.255.241 = Gateway peer B

Prerequisites

- Correct configuration of Outbound Routing components

1. Associate Mediation Pool A with Gateway peer A and Mediation Pool B with Gateway peer B

2. Create Pool-level trunk with following options

- Enable REFER method support (if REFER is supported on gateway peer side)

- Enable Centralized Media Processing if media termination has the same IP as the signaling termination

- Configure appropriate Media Bypass option (media bypass was not used here for simplicity)

- Create translation rules if necessary

3. Create and configure relevant Voice Routes

- Add appropriate PSTN Usages to Voice Routes

- Associate Routes with relevant gateway peers (in our example, CroatiaNationalRoute is associated with both Gateway peer A and Gateway peer B)

- Redundant network link exists between Datacenter A and Datacenter B

Summary

Outbound Routing in Lync Server 2010 provides a lot of granularity in configuring fault tolerant routes. Apart from two mentioned options, there’s another one I haven’t discussed in details above – the scenario when e.g. both Mediation pool in one location is down and at the same time, Gateway peer in other location is down:

If you also associate Mediation Pool A with Gateway peer B and Mediation Pool B with Gateway peer A (in addition to the steps mentioned in Prerequisites), you will enable the call to go through even in above scenario:

Although the topology presented in these examples describes rather complex scenarios with multiple data centers, the similar fault tolerance level can be achieved with much simpler topologies (e.g. single data center, two Standard Edition servers associated with two gateway peers – correct configuration of trunks and routes would enable you the similar level of fault tolerance as described in this article, apart from site resiliency, obviously).

It is worth mentioning that this is not the only way of configuring fault tolerance on outbound routing (e.g. – failover route is another alternatives in some scenarios) and its up to administrators to pick the configuration that best suites their particular requirements.

Limit Media Ports in Office Communications Server 2007 R2 Devices

ToninoF — Sat, 10 Jul 2010 06:32:27 GMT

Administrators are frequently required to limit media ports that are used by Communications Server 2007 R2 clients. This particular task is straightforward to perform for Office Communicator 2007 R2 clients through group policy. For details, see Media Port Range Registry Keys.

However, Office Communicator 2007 R2 Phone Edition is not configurable through group policy and to achieve the same result with Communicator Phone Edition, you have to edit relevant server-side pool settings so devices can receive this information through in-band provisioning in the SIP channel.

I have published an article on NextHop describing the exact procedure to limit media ports for Communicator Phone Edition devices. Complete article can be found at Limit Media Ports in Office Communications Server 2007 R2 Devices

Office Communicator SIP Trace – Multiple Points of Presence (MPOP)

ToninoF — Tue, 12 Jan 2010 16:08:43 GMT

During my work on OCS engagements, I’ve already seen situations where OCS admins would start successful trace of SIP sessions (IM, voice calls, conferences, etc) but at one point they would be “lost” in that bunch of SIP packets in the log. In short – they’d expect to see less messages related to the call than they would find in their logs.

Provided that they correctly sorted SIP messages belonging to the same SIP session (which is easily done by finding all messages with same Call-ID[1]), they’d still see more SIP messages than they’d expect to see.

When talking about Voice Call Flow SIP trace, I didn’t mention one of rather frequent situations you’re going to encounter in your SIP traces: multiple points of presence (MPOP). While I did it on purpose in that particular blog post (for simplicity), it’s necessary to address those scenarios as you will often find in SIP traces more SIP messages (mainly provisional, 1xx replies) than you’d expect, usually due to recipient having multiple registered SIP endpoints (and thus multiple points of presence).

For more detailed information on MPOP, please see Sriram’s blog.

Following examples address such communication where called party (in this case IzabelaF) has logged on with two endpoints: Office Communicator Phone 2007 R2 and Office Communicator 2007 R2, while remote user (MarinoF) uses his OC 2007 R2 client to place a call.

Please note that in parenthesis after each SIP method/header, I’m putting the direction of the message from the caller’s point of view.

[1] Each SIP session is uniquely identified with Call-ID header parameter, so the first step in finding related SIP messages would be to search for all SIP messages with identical Call-ID

SIP Invite (OUT)

Excerpt:

01/05/2010|14:00:47.889 418:D8 INFO :: INVITE sip:izabelaf@uclab.org SIP/2.0
Via: SIP/2.0/TLS 200.1.1.201:2604
Max-Forwards: 70
From: <sip:marinof@uclab.org>;tag=0fae8454e3;epid=1488039028
To: <sip:izabelaf@uclab.org>
Call-ID: e34305289c3b4c368c583f531fddeff3
CSeq: 1 INVITE
Contact: <sip:marinof@uclab.org;opaque=user:epid:NFExHZ6mj1yDHREOYWtdYQAA;gruu>
User-Agent: UCCAPI/3.5.6907.0 OC/3.5.6907.0 (Microsoft Office Communicator 2007 R2)

The first message shows an attempt to setup a SIP session between a caller (sip:marinof@uclab.org) and a called party (sip:izabelaf@uclab.org).

If we skip next two “standard” messages sent from FE server (100 Trying and 183 Session Progress), we’ll see an interesting ms-diagnostics header value in 101 Progress Report message:

101 Progress Report (IN)

Excerpt:

ms-diagnostics: 13004;reason="Request was proxied to one or more registered endpoints";source="R2EE01.uclab.org";appName="InboundRouting"
Server: InboundRouting/3.5.0.0

101 Progress Report shows that the request was handled by server-side Inbound Routing component. Inbound Routing handles incoming calls in such way that it forks the call to all called party’s registered endpoints.

183 Session Progress (endpoint 1) (IN)

Excerpt:

01/05/2010|14:00:48.831 418:D8 INFO :: SIP/2.0 183 Session Progress
ms-user-logon-data: RemoteUser
Authentication-Info: NTLM rspauth="0100000000000000C2EA75A8807B40EA", srand="8E9BFD7E", snum="16", opaque="135DF6CC", qop="auth", targetname="R2EE01.uclab.org", realm="SIP Communications Service"
Via: SIP/2.0/TLS 200.1.1.201:2604;ms-received-port=2604;ms-received-cid=500
From: "Marino Filipovic"<sip:marinof@uclab.org>;tag=0fae8454e3;epid=1488039028
To: <sip:izabelaf@uclab.org>;epid=aad34505db;tag=c34587eaa8
Call-ID: e34305289c3b4c368c583f531fddeff3
CSeq: 1 INVITE
Record-Route: <sip:pool01.uclab.org:5061;transport=tls;ms-fe=R2EE01.uclab.org;opaque=state:F:T:Eu;lr;received=172.31.255.222;ms-received-cid=401>
Contact: <sip:izabelaf@uclab.org;opaque=user:epid:ATX04NzZClmCm9_s1BVjeAAA;gruu>
User-Agent: UCCAPI/3.5.6907.0 OC/3.5.6907.0 (Microsoft Office Communicator 2007 R2)

First 183 Session Progress message shows reply from one of Izabela’s registered endpoints, OC 2007 R2 client, which is visible from User-Agent header value:

User-Agent: UCCAPI/3.5.6907.0 OC/3.5.6907.0 (Microsoft Office Communicator 2007 R2)

Please, pay attention to epid and tag values in To: header. I stressed in my previous blog that you can expect different epid and tag values in To: headers in case recipient has multiple registered endpoints, as those values uniquely identify each registered endpoint. This is also one of very helpful information when differentiating between multiple SIP messages (such as multiple 183 Session Progress messages).

So, lets see the second 183 Session Progress message.

183 Session Progress (endpoint 2) (IN)

Excerpt:

01/05/2010|14:00:49.191 418:D8 INFO :: SIP/2.0 183 Session Progress
ms-user-logon-data: RemoteUser
Authentication-Info: NTLM rspauth="01000000000000005DBAB6FE807B40EA", srand="B48CE0F0", snum="19", opaque="135DF6CC", qop="auth", targetname="R2EE01.uclab.org", realm="SIP Communications Service"
Via: SIP/2.0/TLS 200.1.1.201:2604;ms-received-port=2604;ms-received-cid=500
From: "Marino Filipovic"<sip:marinof@uclab.org>;tag=0fae8454e3;epid=1488039028
To: <sip:izabelaf@uclab.org>;epid=2798f0b3cc;tag=97a7d6045d
Call-ID: e34305289c3b4c368c583f531fddeff3
CSeq: 1 INVITE
Record-Route: <sip:pool01.uclab.org:5061;transport=tls;ms-fe=R2EE01.uclab.org;opaque=state:F:T:Eu;lr;received=172.31.255.222;ms-received-cid=401>
Contact: <sip:izabelaf@uclab.org;opaque=user:epid:uozeqPgOuFOVd0DaRpeFCgAA;gruu>
User-Agent: CPE/3.5.6907.0 OCPhone/3.5.6907.0 (Office Communicator Phone 2007 R2)

Second 183 Session Progress message shows reply from another Izabela’s registered endpoint: this time it’s Office Communicator Phone (User-Agent: CPE/3.5.6907.0 OCPhone/3.5.6907.0 (Office Communicator Phone 2007 R2)).

If you click on screenshots in both 183 messages you will see SDP data containing ICE protocol details used to establish media flow between the caller and called party. This is nothing else than answer to SDP offer sent in first analyzed packet (SIP Invite from Marino) where you can find two SDP blocks (to accommodate both R1 and R2 OC clients, as mentioned in my previous blog) with Marino’s candidates to be used for establishing media flow.

Note: ICE negotiation has several phases which is not within the scope of this blog post, but just for informational purposes let’s say that the actions performed during media path negotiation are: address discovery and exchange, connectivity check and address candidate promotion.

Note: It’s important to stress that SDP details can be seen in provisional (1xx) messages only in case of OCS 2007 R2 and later. In previous releases, SDP offer with caller’s ICE candidates would still be sent in SIP Invite message, but called party would reply with it’s own candidates in 200 OK message which would sometimes lead to first Hello going unheard. As of OCS 2007 R2, the support for early media is added so that media negotiation starts before the call is actually answered by called party. It’s also necessary that endpoints support early media which is the case with OCS 2007 R2 and later endpoints.

200 OK (IN)

Excerpt:

01/05/2010|14:00:59.296 418:D8 INFO :: SIP/2.0 200 OK
ms-user-logon-data: RemoteUser
Authentication-Info: NTLM rspauth="01000000000000007CA5BF76807B40EA", srand="5F94A5D3", snum="21", opaque="135DF6CC", qop="auth", targetname="R2EE01.uclab.org", realm="SIP Communications Service"
P-Asserted-Identity: <sip:izabelaf@uclab.org>, <tel:+38514802551>
Via: SIP/2.0/TLS 200.1.1.201:2604;ms-received-port=2604;ms-received-cid=500
From: "Marino Filipovic"<sip:marinof@uclab.org>;tag=0fae8454e3;epid=1488039028
To: <sip:izabelaf@uclab.org>;epid=2798f0b3cc;tag=97a7d6045d
Call-ID: e34305289c3b4c368c583f531fddeff3
CSeq: 1 INVITE
Record-Route: <sip:pool01.uclab.org:5061;transport=tls;ms-fe=R2EE01.uclab.org;opaque=state:F:T:Eu;lr;received=172.31.255.222;ms-received-cid=401>
Contact: <sip:izabelaf@uclab.org;opaque=user:epid:uozeqPgOuFOVd0DaRpeFCgAA;gruu>
User-Agent: CPE/3.5.6907.0 OCPhone/3.5.6907.0 (Office Communicator Phone 2007 R2)
.

. (cut due to simplicity)

a=ice-ufrag:Ec9d
a=ice-pwd:EWRPxB9CrdW64VXL1trp587N
a=candidate:1 1 UDP 2130706431 172.31.255.73 32039 typ host
a=candidate:1 2 UDP 2130705918 172.31.255.73 3599 typ host
a=candidate:2 1 TCP-PASS 6556159 200.1.1.20 51553 typ relay raddr 200.1.1.20 rport 51553
a=candidate:2 2 TCP-PASS 6556158 200.1.1.20 51553 typ relay raddr 200.1.1.20 rport 51553
a=candidate:3 1 UDP 16648703 200.1.1.20 52279 typ relay raddr 200.1.1.20 rport 52279
a=candidate:3 2 UDP 16648702 200.1.1.20 57326 typ relay raddr 200.1.1.20 rport 57326
a=candidate:4 1 TCP-ACT 7076863 200.1.1.20 51553 typ relay raddr 200.1.1.20 rport 51553
a=candidate:4 2 TCP-ACT 7076350 200.1.1.20 51553 typ relay raddr 200.1.1.20 rport 51553
a=candidate:5 1 TCP-ACT 1684797951 172.31.255.73 31247 typ srflx raddr 172.31.255.73 rport 31247
a=candidate:5 2 TCP-ACT 1684797438 172.31.255.73 31247 typ srflx raddr 172.31.255.73 rport 31247

Although media negotiations starts before the call is answered (to accommodate early-media requirements), the called party still sends its final candidates (from the endpoint that answered the call) in 200 OK message to complete ICE negotiation.

Note: what is not visible from this trace (as that is communication between the server and the other endpoint) is that server cancels invitation to the other endpoint using SIP CANCEL method.

ACK (OUT)

Excerpt:

01/05/2010|14:00:59.456 418:D8 INFO :: ACK sip:izabelaf@uclab.org;opaque=user:epid:uozeqPgOuFOVd0DaRpeFCgAA;gruu SIP/2.0
Via: SIP/2.0/TLS 200.1.1.201:2604
Max-Forwards: 70
From: <sip:marinof@uclab.org>;tag=0fae8454e3;epid=1488039028
To: <sip:izabelaf@uclab.org>;epid=2798f0b3cc;tag=97a7d6045d
Call-ID: e34305289c3b4c368c583f531fddeff3
CSeq: 1 ACK
Route: <sip:sip.uclab.org:443;transport=tls;opaque=state:Ci.R500;lr;ms-route-sig=babjyotg5YrHahdExfv5G_R78glc6rHo0ChevgyAAA>
Route: <sip:pool01.uclab.org:5061;transport=tls;ms-fe=R2EE01.uclab.org;opaque=state:F:T:Eu;lr;received=172.31.255.222;ms-received-cid=401>
User-Agent: UCCAPI/3.5.6907.0 OC/3.5.6907.0 (Microsoft Office Communicator 2007 R2)
Supported: ms-dialog-route-set-update
Proxy-Authorization: NTLM qop="auth", realm="SIP Communications Service", opaque="135DF6CC", targetname="R2EE01.uclab.org", crand="a1b5d2ce", cnum="15", response="0100000000000000adf58669807b40ea"

SIP session three way handshake completes with acknowledgement from Marino’s endpoint to Izabela’s endpoint that was picked to answer the call.

SIP INVITE (OUT)

Excerpt:

01/05/2010|14:01:04.934 418:D8 INFO :: INVITE sip:izabelaf@uclab.org;opaque=user:epid:uozeqPgOuFOVd0DaRpeFCgAA;gruu SIP/2.0
Via: SIP/2.0/TLS 200.1.1.201:2604
Max-Forwards: 70
From: <sip:marinof@uclab.org>;tag=0fae8454e3;epid=1488039028
To: <sip:izabelaf@uclab.org>;epid=2798f0b3cc;tag=97a7d6045d
Call-ID: e34305289c3b4c368c583f531fddeff3
CSeq: 3 INVITE
Route: <sip:sip.uclab.org:443;transport=tls;opaque=state:Ci.R500;lr;ms-route-sig=babjyotg5YrHahdExfv5G_R78glc6rHo0ChevgyAAA>
Route: <sip:pool01.uclab.org:5061;transport=tls;ms-fe=R2EE01.uclab.org;opaque=state:F:T:Eu;lr;received=172.31.255.222;ms-received-cid=401>
Contact: <sip:marinof@uclab.org;opaque=user:epid:NFExHZ6mj1yDHREOYWtdYQAA;gruu>
User-Agent: UCCAPI/3.5.6907.0 OC/3.5.6907.0 (Microsoft Office Communicator 2007 R2)
.

. (cut due to simplicity)

a=candidate:1 1 UDP 2130706431 200.1.1.201 50016 typ host
a=candidate:1 2 UDP 2130705918 200.1.1.201 50018 typ host
a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:JTZf0de/tIGNK+5aQmVJCgslAzCLYsPwNJgG/Ga+|2^31|1:1
a=remote-candidates:1 200.1.1.20 52279 2 200.1.1.20 57326

After ICE connectivity check and candidate promotion is completed (very detailed information can be found in Bernd’s blog), Marino is sending the second SIP INVITE with chosen candidates (both local and remote), which can be seen in above excerpt.

200 OK (IN)

Excerpt:

01/05/2010|14:01:05.154 418:D8 INFO :: SIP/2.0 200 OK
ms-user-logon-data: RemoteUser
Authentication-Info: NTLM rspauth="01000000000000006A0598A9807B40EA", srand="E662685E", snum="27", opaque="135DF6CC", qop="auth", targetname="R2EE01.uclab.org", realm="SIP Communications Service"
Via: SIP/2.0/TLS 200.1.1.201:2604;ms-received-port=2604;ms-received-cid=500
From: <sip:marinof@uclab.org>;tag=0fae8454e3;epid=1488039028
To: <sip:izabelaf@uclab.org>;epid=2798f0b3cc;tag=97a7d6045d
Call-ID: e34305289c3b4c368c583f531fddeff3
CSeq: 3 INVITE
Record-Route: <sip:pool01.uclab.org:5061;transport=tls;ms-fe=R2EE01.uclab.org;opaque=state:F:T:Eu;lr;received=172.31.255.222;ms-received-cid=401>
Contact: <sip:izabelaf@uclab.org;opaque=user:epid:uozeqPgOuFOVd0DaRpeFCgAA;gruu>
User-Agent: CPE/3.5.6907.0 OCPhone/3.5.6907.0 (Office Communicator Phone 2007 R2)
.

. (cut due to simplicity)

a=candidate:3 1 UDP 16648703 200.1.1.20 52279 typ relay raddr 200.1.1.20 rport 52279
a=candidate:3 2 UDP 16648702 200.1.1.20 57326 typ relay raddr 200.1.1.20 rport 57326
a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:kSYTWb/FPgCEeGKC1/6z4in0Nr1gNfYymLwBMfCc|2^31|1:1
a=remote-candidates:1 200.1.1.201 50016 2 200.1.1.201 50018

Izabela’s client confirms the candidates and formally completes the candidate negotiation.

Summary

When tracing a particular SIP session you might encounter slightly more complex traces than you usually would see in the logs. Reasons could be various: simultaneous ringing set on called party’s side, delegation, but also that called party has multiple registered endpoints in which case each endpoint would reply to initial SIP INVITE. However, you’ll notice that only one of those endpoints (the one that picked the call) would complete the three way handshake process (INVITE/200 OK/ACK).

Although it might look confusing to see multiple 180 and 183 messages, paying attention to tag and epid values in To: header will help resolve most doubts. As for multiple 200 OK messages in the same SIP session, it’s very helpful to check CSeq header value in each 200 OK message, as it identifies a particular transaction (looking at CSeq values, you will see that some of those 200 OK messages belong to first INVITE, some to PRACK and some to second INVITE).

Office Communicator SIP Trace – Voice Call Flow

ToninoF — Thu, 19 Nov 2009 17:07:33 GMT

When using Office Communicator to place a voice call, you can use several different ways to establish a call:

clicking on a Communicator Call option next to the contact in your OC, thus using contact’s SIP URI to place a call
dialing E.164 number
dialing non-E.164 number and letting OCS “normalize” the number

Whatever way you choose to place a call, several OCS server-side components will be involved in call establishment, so let’s first shortly define what each of those components do:

Inbound Routing – handles incoming calls, taking into account user’s call-forwarding settings (e.g. if user configured the call forwarding settings so that incoming calls is forwarded to his/her cell phone, inbound routing would take care that the call is handled accordingly).
Translation Application – uses normalization rules based on user’s location profile to translate dialed number into a standard E.164 number. For complete information, let’s say that client also obtains normalization rules together with other configuration data through in-band provisioning process (more information in Jens Trier Rasmussen’s blog)
Outbound Routing – calls that are not destined to users hosted on OCS (when normalized number cannot be matched to any existing SIP URI) are transferred to Outbound Routing component that applies call authorization rules to callers and route the calls to PBX or PSTN.
User Services – handles several aspects of Office Communications Server (IM, Presence, Conferencing features) but is also very important for Enterprise voice functionality where it performs Reverse Number Lookup on the phone number of each incoming call and tries to match that number to a SIP URI. If a match is found the call is for an OCS-enabled user and stays within OCS environment, but if there is no match, the call has to be handled by Outbound Routing component that will route the call to PBX or PSTN.

Let’s see how SIP traces differ depending on which call scenario is used: SIP URI (Communicator Call), E.164 number or non-E.164 number.

Note: I am providing background information about SIP headers and parameters after first SIP INVITE message only, since majority of these headers are repeating in subsequent packets. New headers and parameters in later packets that are important for this article will be explained as well, where necessary. For more detailed information, though, please refer to RFCs and other articles often mentioned as references throughout this blog post.

Since analyzing all SIP packets in each call would be rather tiresome (and unnecessary) business, I will take three typical packets that can provide enough information to achieve this articles purpose: SIP INVITE, Progress Report and Session Progress messages.

Scenario 1: Calling basic[1] SIP URI (Communicator Call)

In this first example we’ll check what happens when you choose Communicator Call option when calling one of your contacts.

SIP INVITE

11/16/2009|16:52:21.441 2A0:F34 INFO :: Sending Packet - 200.1.1.20:443 (From Local Address: 200.1.1.201:2262) 5107 bytes:

11/16/2009|16:52:21.441 2A0:F34 INFO :: INVITE sip:izabelaf@uclab.org SIP/2.0

Via: SIP/2.0/TLS 200.1.1.201:2262

Max-Forwards: 70

From: <sip:marinof@uclab.org>;tag=fda796badd;epid=1488039028

To: <sip:izabelaf@uclab.org>

Call-ID: 0aee2d6389294d18af28ae9f219a3420

CSeq: 1 INVITE

Contact: <sip:marinof@uclab.org;opaque=user:epid:NFExHZ6mj1yDHREOYWtdYQAA;gruu>

User-Agent: UCCAPI/3.5.6907.0 OC/3.5.6907.0 (Microsoft Office Communicator 2007 R2)

Ms-Conversation-ID: Acpm1MgQioYa3RnkRyeZp67T413HPw==

Supported: timer

Supported: histinfo

Supported: ms-safe-transfer

Supported: ms-sender

Supported: ms-early-media

Supported: Replaces

Supported: 100rel

ms-keep-alive: UAC;hop-hop=yes

Allow: INVITE, BYE, ACK, CANCEL, INFO, UPDATE, REFER, NOTIFY, BENOTIFY, OPTIONS

P-Preferred-Identity: <sip:marinof@uclab.org>, <tel:+38517654321>

Supported: ms-conf-invite

Proxy-Authorization: NTLM qop="auth", realm="SIP Communications Service", opaque="628A7332", targetname="R2EE01.uclab.org", crand="c3ed0454", cnum="12", response="010000006e646964cf67ad685412cf8b"

Content-Type: multipart/alternative;boundary="----=_NextPart_000_0007_01CA66DD.2A245470"

Content-Length: 3968

------=_NextPart_000_0007_01CA66DD.2A245470

Content-Type: application/sdp

Content-Transfer-Encoding: 7bit

Content-Disposition: session; handling=optional; ms-proxy-2007fallback

Trace 1.1 – INVITE: Session setup using SIP URI of the called party (SDP offer (blue font) is truncated due to clarity)

The first packet shows the caller (sip:marinof@uclab.org) calling the other party using her SIP URI (sip:izabelaf@uclab.org). Since Request URI[2] already contains a SIP URI of a called party, there is no action whatsoever from the Translation Application side, nor from User Services side.

This means that there is no need to neither normalize non-E.164 number to E.164 (as there’s nothing to normalize), nor there is a need to match E.164 number to SIP-URI (as SIP URI is already there).

A little bit more detailed look at this first packet will reveal several interesting facts about establishing the call:

First, it shows session setup for which SIP uses an INVITE method[3]. Each session is uniquely identified by the From and To headers with tag and epid parameters and with the Call-ID[4].

As can be seen, the INVITE has been sent to (example) address 200.1.1.20 (which is an Access Edge server for uclab.org SIP domain) on a port dedicated for remote user access (443). The request is sent from the remote host which will be visible in one of the replies (ms-user-logon-data: RemoteUser), such as in Trace 1.2 – Progress Report.

“Contact” header contains URI registered by the user (sip:marinof@uclab.org) that provides contact information for other party in the call.

“Supported” headers contain a list of supported options such as 100rel (ability to send provisional responses to INVITE messages in a reliable way), … and one very important option: ms-early-media.[5]

ms-early-media is a proprietary extension to SIP Supported header, and denotes client’s ability to receive an SDP answer in a provisional 18x message (apart from standard way through reliable 200 message). Effectively, this means that media exchange can start even before session is fully established.

“P-Preferred-Identity” header is generated by user agent when it needs to communicate an additional identity of the user (apart from the one in the From: header)[6]. This identity would later be used by trusted proxy to create P-Asserted-Identity value.

“Proxy-authorization” header was mentioned in more details in previous blog (Office Communicator SIP Trace Analysis – Registration ), so let’s just note here that in this particular session it shows that NTLM auth is used (Proxy-Authorization: NTLM), protection method used is authentication only, not integrity protection (qop=auth) and that response parameter caries client’s message signature.

Listing all headers found in INVITE message is far beyond the scope of this article, but two of these should not be omitted at least from short explanation: Via and Record-Route headers. Record-Route is added by proxies who decide to stay in the path of all responses to initial request, while Via header contains transport protocol used (SIP/2.0/TLS) and the client IP address:port combination.

Next part of this first packet (after Content-Length header) shows start of SDP Offer, but I removed it for the sake of clarity. If it weren’t removed, you’d see that there were two very similar SDP messages in this first INVITE message - to accommodate both OC 2007 (R1) and OC 2007 R2 clients.

First SDP message starting with ms-proxy-2007fallback parameter in Content-Disposition header is for R1 client while the second one is for R2 client.

Detailed SDP analysis is beyond the scope of this article, so if you want to dive deeper in SDP and media exchange negotiation itself, I’d highly recommend reading Bernd Ott’s blog at Communications Server Team Blog site. Apart from SDP details, Bernd provides excellent analysis of media traversal over NAT, which itself is very interesting reading.

The next analyzed trace will be the 101 Progress Report message sent by Front End server’s Inbound Routing component.

101 Progress Report

11/16/2009|16:52:21.612 2A0:F34 INFO :: Data Received - 200.1.1.20:443 (To Local Address: 200.1.1.201:2262) 697 bytes:

11/16/2009|16:52:21.612 2A0:F34 INFO :: SIP/2.0 101 Progress Report

ms-user-logon-data: RemoteUser

Authentication-Info: NTLM rspauth="0100000000000000BC4976EB5412CF8B", srand="7756C6C0", snum="14", opaque="628A7332", qop="auth", targetname="R2EE01.uclab.org", realm="SIP Communications Service"

Content-Length: 0

Via: SIP/2.0/TLS 200.1.1.201:2262;ms-received-port=2262;ms-received-cid=2D00

From: "Marino Filipovic"<sip:marinof@uclab.org>;tag=fda796badd;epid=1488039028

To: <sip:izabelaf@uclab.org>

Call-ID: 0aee2d6389294d18af28ae9f219a3420

CSeq: 1 INVITE

ms-diagnostics: 13004;reason="Request was proxied to one or more registered endpoints";source="R2EE01.uclab.org";appName="InboundRouting"

Server: InboundRouting/3.5.0.0

Trace 1.2 – Progress Report

ms-diagnostics[7] header in Progress Report trace contains some interesting information - it shows that Inbound Routing application will proxy the call to one or more called party’s registered SIP endpoints. In case of more than one registered endpoint for the called party, the call would be forked to all registered endpoints. Server header found in Progress Report does not denote physical server, but rather server-side application responsible for handling client’s request.

The next interesting packet (Trace 1.3) shows Session Progress in which you can see two Record-Route headers (defined earlier in the text) with values of Access Proxy server (sip:sip.uclab.org:443) and OCS pool (sip:pool01.uclab.org:5061). Please pay attention to ms-fe parameter found in first Record-Route header value (ms-fe=r2ee01.uclab.org). When SIP server is a member of a pool of servers that share the same FQDN (in this case pool01.uclab.org), ms-fe parameter enables particular member of the pool (that is working on the request), to put its own, unique FQDN (ms-fe=r2ee01.uclab.org) and denote the particular member of the pool that should stay in the path of future SIP message exchanges.

183 Session Progress

11/16/2009|16:52:22.443 2A0:F34 INFO :: Data Received - 200.1.1.20:443 (To Local Address: 200.1.1.201:2262) 2585 bytes:

11/16/2009|16:52:22.443 2A0:F34 INFO :: SIP/2.0 183 Session Progress

ms-user-logon-data: RemoteUser

Authentication-Info: NTLM rspauth="01000000000000001DC9DAC65412CF8B", srand="77BAA84A", snum="16", opaque="628A7332", qop="auth", targetname="R2EE01.uclab.org", realm="SIP Communications Service"

Via: SIP/2.0/TLS 200.1.1.201:2262;ms-received-port=2262;ms-received-cid=2D00

From: "Marino Filipovic"<sip:marinof@uclab.org>;tag=fda796badd;epid=1488039028

To: <sip:izabelaf@uclab.org>;epid=2798f0b3cc;tag=5e5e12af1a

Call-ID: 0aee2d6389294d18af28ae9f219a3420

CSeq: 1 INVITE

Record-Route: <sip:pool01.uclab.org:5061;transport=tls;ms-fe=R2EE01.uclab.org;opaque=state:F:T:Eu;lr;received=172.31.255.222;ms-received-cid=2701>

Contact: <sip:izabelaf@uclab.org;opaque=user:epid:uozeqPgOuFOVd0DaRpeFCgAA;gruu>

User-Agent: CPE/3.5.6907.0 OCPhone/3.5.6907.0 (Office Communicator Phone 2007 R2)

Require: 100rel

RSeq: 1

Content-Type: application/sdp

Content-Length: 1520

Record-Route: <sip:sip.uclab.org:443;transport=tls;opaque=state:Ci.R2d00;lr;ms-route-sig=gadu3AbEKriSVtRh1_ODE_CC6EuF7pPgc70lwmrQAA>

v=0

o=- 0 0 IN IP4 172.31.255.71

s=session

c=IN IP4 172.31.255.71

b=CT:99980

t=0 0

m=audio 2879 RTP/SAVP 114 111 115 8 0 97 13 118 101

a=ice-ufrag:hfAS

a=ice-pwd:MNL10SujMvycj08p4UH/lP02

a=candidate:1 1 UDP 2130706431 172.31.255.71 2879 typ host

a=candidate:1 2 UDP 2130705918 172.31.255.71 20457 typ host

Trace 1.3 - Session Progress carrying SDP Answer

The Session Progress message shows that called party (sip:izabelaf@uclab.org) has registered OC Phone endpoint (User-Agent: CPE/3.5.6907.0 OCPhone/3.5.6907.0 (Office Communicator Phone 2007 R2) . If called party has registered more than one SIP endpoint, the caller would receive multiple 183 Session Progress messages, but in that case tag and epid parameters in To: header would carry different values in these separate messages (To-tag and epid parameters uniquely identify each registered endpoint). You can also see an answer to initial SDP Offer found in INVITE message (truncated due to clarity). This is where R2 client differs from R1 in which you could find an SDP Answer only later in 200 OK response (as there was no support for early media in previous client version^{^[8]}).

Scenario 2: Calling E.164 number

Following traces show how session setup differs when user dials using E.164 number. In the first place, you’ll see some additional server components involved as this call has destination outside of OCS environment (either on other PBX or PSTN).

SIP INVITE

11/16/2009|17:02:04.249 2A0:F34 INFO :: Sending Packet - 200.1.1.20:443 (From Local Address: 200.1.1.201:2262) 5137 bytes:

11/16/2009|17:02:04.249 2A0:F34 INFO :: INVITE sip:+38511234567@uclab.org;user=phone SIP/2.0

Via: SIP/2.0/TLS 200.1.1.201:2262

Max-Forwards: 70

From: <sip:marinof@uclab.org>;tag=d089e797cf;epid=1488039028

To: <sip:+38511234567@uclab.org;user=phone>

Call-ID: 036f540493ef4d089dff7c50d197b43f

CSeq: 1 INVITE

Contact: <sip:marinof@uclab.org;opaque=user:epid:NFExHZ6mj1yDHREOYWtdYQAA;gruu>

User-Agent: UCCAPI/3.5.6907.0 OC/3.5.6907.0 (Microsoft Office Communicator 2007 R2)

Ms-Conversation-ID: Acpm1iN/R7sNneRNT8eC9BppFFWX+w==

Supported: timer

Supported: histinfo

Supported: ms-safe-transfer

Supported: ms-sender

Supported: ms-early-media

Supported: Replaces

Supported: 100rel

ms-keep-alive: UAC;hop-hop=yes

Allow: INVITE, BYE, ACK, CANCEL, INFO, UPDATE, REFER, NOTIFY, BENOTIFY, OPTIONS

P-Preferred-Identity: <sip:marinof@uclab.org>, <tel:+38517654321>

Supported: ms-conf-invite

Proxy-Authorization: NTLM qop="auth", realm="SIP Communications Service", opaque="628A7332", targetname="R2EE01.uclab.org", crand="2d80635e", cnum="46", response="010000006e646964031f26bd5412cf8b"

Content-Type: multipart/alternative;boundary="----=_NextPart_000_0016_01CA66DE.85874C90"

Content-Length: 3968

------=_NextPart_000_0016_01CA66DE.85874C90

Content-Type: application/sdp

Content-Transfer-Encoding: 7bit

Content-Disposition: session; handling=optional; ms-proxy-2007fallback

v=0

o=- 0 0 IN IP4 200.1.1.20

s=session

c=IN IP4 200.1.1.20

b=CT:99980

t=0 0

m=audio 52828 RTP/AVP 114 111 112 115 116 4 8 0 97 13 118 101

k=base64:8nz2U+Sr7tkJOyxCVKRXT1JoEwganb5OVW5QFs5v40hiBx3fuyzPa+oHcHTH

a=candidate:Y/dexvxW+WxmsamABmy6olEMpPbYL4muLNDd+Hb/BHs 1 ei885sgdxFjptCgFT+bAJg UDP 0.860 200.1.1.201 50007

a=candidate:Y/dexvxW+WxmsamABmy6olEMpPbYL4muLNDd+Hb/BHs 2 ei885sgdxFjptCgFT+bAJg UDP 0.860 200.1.1.201 50002

Trace 2.1 – INVITE showing user=phone parameter

It’s important to stress the significant difference in Request URI compared to Scenario 1 :

INVITE sip:+38511234567@uclab.org;user=phone SIP/2.0.

Apart from visible difference in first part of SIP URI (phone number instead of user alias), a new parameter user=phone is added which denotes that SIP URI is in phone number format. Again, an SDP details follow (and again truncated significantly due to clarity)

101 Progress Report

The second trace shows Progress Report which again differs from the equivalent packet in Scenario 1.

11/16/2009|17:02:04.470 2A0:F34 INFO :: Data Received - 200.1.1.20:443 (To Local Address: 200.1.1.201:2262) 868 bytes:

11/16/2009|17:02:04.470 2A0:F34 INFO :: SIP/2.0 101 Progress Report

ms-user-logon-data: RemoteUser

Authentication-Info: NTLM rspauth="0100000000000000517441485412CF8B", srand="7EBD2724", snum="55", opaque="628A7332", qop="auth", targetname="R2EE01.uclab.org", realm="SIP Communications Service"

Content-Length: 0

Via: SIP/2.0/TLS 200.1.1.201:2262;ms-received-port=2262;ms-received-cid=2D00

From: "Marino Filipovic"<sip:marinof@uclab.org>;tag=d089e797cf;epid=1488039028

To: <sip:+38511234567@uclab.org;user=phone>

Call-ID: 036f540493ef4d089dff7c50d197b43f

CSeq: 1 INVITE

ms-diagnostics: 12006;reason="Trying next hop";source="R2EE01.uclab.org";PhoneUsage="CN={AB77AE74-F9B1-480F-B7CD-79792BC13D87},CN=Phone Route Usages,CN=RTC Service,CN=Services,CN=Configuration,DC=uclab,DC=org";PhoneRoute="Local Calls";Gateway="R2MS01.uclab.org:5061";appName="OutboundRouting"

Server: OutboundRouting/3.5.0.0

Trace 2.2 – Progress Report

ms-diagnostics header value in 101 Progress Report this time shows that another server side component is involved: Outbound Routing. The reason behind involvement of Outbound Routing component is rather simple: E.164 number of the called party (+38511234567) could not be matched to any existing SIP URI, which shows that the called party is either on a PBX system or PSTN, so the call has to be routed out of OCS system to the next hop using Local Calls route (PhoneRoute="Local Calls";Gateway="R2MS01.uclab.org:5061"). Just a note that apart from finding the best route for the call, Outbound Routing also performs a call authorization (in a nutshell, it is matching normalized number and caller’s Voice Policy phone usages to the number pattern and phone usages in available routes).

183 Session Progress

11/16/2009|17:02:04.690 2A0:F34 INFO :: Data Received - 200.1.1.20:443 (To Local Address: 200.1.1.201:2262) 2650 bytes:

11/16/2009|17:02:04.690 2A0:F34 INFO :: SIP/2.0 183 Session Progress

ms-user-logon-data: RemoteUser

Via: SIP/2.0/TLS 200.1.1.201:2262;ms-received-port=2262;ms-received-cid=2D00

Authentication-Info: NTLM rspauth="0100000000000000260310965412CF8B", srand="CDB978E7", snum="56", opaque="628A7332", qop="auth", targetname="R2EE01.uclab.org", realm="SIP Communications Service"

FROM: "Marino Filipovic"<sip:marinof@uclab.org>;tag=d089e797cf;epid=1488039028

TO: <sip:+38511234567@uclab.org;user=phone>;tag=2fe83c9f;epid=B6EE6ACB83

CSEQ: 1 INVITE

CALL-ID: 036f540493ef4d089dff7c50d197b43f

RECORD-ROUTE: <sip:pool01.uclab.org:5061;transport=tls;ms-fe=R2EE01.uclab.org;opaque=state:F;lr;received=172.31.255.222;ms-received-cid=2701>

CONTACT: <sip:R2MS01.uclab.org@uclab.org;gruu;opaque=srvr:MediationServer:XDQqnDzOpESpnFD0MajmKgAA>;isGateway

CONTENT-LENGTH: 1558

SUPPORTED: gruu-10

CONTENT-TYPE: application/sdp

ALLOW: UPDATE

REQUIRE: 100rel

SERVER: RTCC/3.5.0.0 MediationServer

Rseq: 1

Record-Route: <sip:sip.uclab.org:443;transport=tls;opaque=state:Ci.R2d00;lr;ms-route-sig=gasAR62MgLINIzHBRWokPQinSiu77VVVbz0lwmrQAA>

v=0

o=- 0 0 IN IP4 172.31.255.223

s=session

c=IN IP4 172.31.255.223

b=CT:1000

t=0 0

m=audio 62724 RTP/SAVP 0 8 115 13 118 97 101

c=IN IP4 172.31.255.247

a=rtcp:60177

a=ice-ufrag:xVRU

a=ice-pwd:oI+0a7+PQL8RD5eS+xaTrDsJ

a=candidate:1 1 UDP 2130706431 172.31.255.247 62724 typ host

a=candidate:1 2 UDP 2130705918 172.31.255.247 60177 typ host

Trace 2.3 –Session Progress

The 183 Session Progress packet is sent from Mediation Server that in turn sends an SDP Answer, sending its own candidates to the client.

In this particular case where remote user places a call to PSTN, the Mediation server acts as an ICE client. Although media connectivity and firewall traversal is completely different topic out of this article’s scope, let’s just be aware that Mediation Server not only does codec translation and encapsulation of SIP into TLS, but it also acts as an ICE client for calls where one party is outside of organization (remote user) and the other one is on PSTN or PBX. For such call to be established at all, it’s necessary for media to traverse firewall, AV Edge, and Mediation server, before it’s finally sent to the gateway and PSTN or PBX. To establish the most optimal media path along this way, it’s necessary to use ICE and Mediation server thus acts as an ICE client in such call scenarios.

One more detail worth mentioning in this trace is the isGateway parameter of the Contact header:

CONTACT: <sip:R2MS01.uclab.org@uclab.org;gruu;opaque=srvr:MediationServer:XDQqnDzOpESpnFD0MajmKgAA>;isGateway

A SIP User Agent stamping isGateway parameter in the Contact header denotes that it has a role of the gateway.

Scenario 3: Calling non-E.164 number

The third scenario happens in situations when user types in the number that is not in E.164 format and the client cannot normalize the number using existing rules.^{^[9]}

SIP INVITE

11/17/2009|18:22:36.901 E54:F68 INFO :: Sending Packet - 200.1.1.20:443 (From Local Address: 200.1.1.201:2389) 5188 bytes:

11/17/2009|18:22:36.901 E54:F68 INFO :: INVITE sip:3123456;phone-context=zagreb.uclab.org@uclab.org;user=phone SIP/2.0

Via: SIP/2.0/TLS 200.1.1.201:2389

Max-Forwards: 70

From: <sip:marinof@uclab.org>;tag=0c0ef918e6;epid=1488039028

To: <sip:3123456;phone-context=zagreb.uclab.org@uclab.org;user=phone>

Call-ID: bcd9cff8600c4b2487845f5ae211f7c6

CSeq: 2 INVITE

Contact: <sip:marinof@uclab.org;opaque=user:epid:NFExHZ6mj1yDHREOYWtdYQAA;gruu>

User-Agent: UCCAPI/3.5.6907.0 OC/3.5.6907.0 (Microsoft Office Communicator 2007 R2)

Ms-Conversation-ID: Acpnqo4mdWwkauuDSkmzOozY9Es0ow==

Supported: timer

Supported: histinfo

Supported: ms-safe-transfer

Supported: ms-sender

Supported: ms-early-media

Supported: Replaces

Supported: 100rel

ms-keep-alive: UAC;hop-hop=yes

Allow: INVITE, BYE, ACK, CANCEL, INFO, UPDATE, REFER, NOTIFY, BENOTIFY, OPTIONS

P-Preferred-Identity: <sip:marinof@uclab.org>, <tel:+38517654321>

Supported: ms-conf-invite

Proxy-Authorization: NTLM qop="auth", realm="SIP Communications Service", opaque="5C3ADF72", targetname="R2EE01.uclab.org", crand="f8c12e13", cnum="2", response="010000006e64696432ff475bdb3f8ba6"

Content-Type: multipart/alternative;boundary="----=_NextPart_000_003F_01CA67B2.F06D3950"

Content-Length: 3968

------=_NextPart_000_003F_01CA67B2.F06D3950

Content-Type: application/sdp

Content-Transfer-Encoding: 7bit

Content-Disposition: session; handling=optional; ms-proxy-2007fallback

v=0

o=- 0 0 IN IP4 200.1.1.20

s=session

c=IN IP4 200.1.1.20

b=CT:99980

t=0 0

m=audio 53192 RTP/AVP 114 111 112 115 116 4 8 0 97 13 118 101

k=base64:zNM45WUMx3rM0ia1GYK/7sjrazYa0XKuCtvlw40qdhd+WUD8fy3JmhylaxHh

a=candidate:kp5leWkR7rFrrXLbl2zQ+XD/6kw/e9Ho/onLrkYUg54 1 6IWEArE1V0Pud+C/oHj+iA UDP 0.890 200.1.1.201 50018

a=candidate:kp5leWkR7rFrrXLbl2zQ+XD/6kw/e9Ho/onLrkYUg54 2 6IWEArE1V0Pud+C/oHj+iA UDP 0.890 200.1.1.201 50007

Trace 3.1 – INVITE showing Phone-context parameter

The new header, seen for the first time in this scenario, is Phone-Context header (INVITE sip:3123456;phone-context=zagreb.uclab.org@uclab.org;user=phone SIP/2.0).

Phone-Context header can be found when Request URI contains neither basic SIP URI, nor phone number in E.164 format. The value of Phone-Context header is the name of user’s Location Profile (zagreb.uclab.org) where location profile contains all necessary normalization rules to translate user-entered phone number. More details on this visible from next Progress Report packet, sent by Translation Service.

101 Progress Report (1)

11/17/2009|18:22:39.014 E54:F68 INFO :: Data Received - 200.1.1.20:443 (To Local Address: 200.1.1.201:2389) 912 bytes:

11/17/2009|18:22:39.014 E54:F68 INFO :: SIP/2.0 101 Progress Report

ms-user-logon-data: RemoteUser

Authentication-Info: NTLM rspauth="0100000000000000106D7D7BDB3F8BA6", srand="70653AFF", snum="10", opaque="5C3ADF72", qop="auth", targetname="R2EE01.uclab.org", realm="SIP Communications Service"

Content-Length: 0

Via: SIP/2.0/TLS 200.1.1.201:2389;ms-received-port=2389;ms-received-cid=4000

From: <sip:marinof@uclab.org>;tag=0c0ef918e6;epid=1488039028

To: <sip:3123456;phone-context=zagreb.uclab.org@uclab.org;user=phone>

Call-ID: bcd9cff8600c4b2487845f5ae211f7c6

CSeq: 2 INVITE

ms-diagnostics: 14011;reason="Called Number translated";source="R2EE01.uclab.org";RuleName="3test";RuleDN="CN={24428855-3EEA-42DC-A6EC-A2CD2F3F43D1},CN=Location Normalization Rules,CN=RTC Service,CN=Services,CN=Configuration,DC=uclab,DC=org";CalledNumber="3123456";TranslatedNumber="+38535123456";appName="TranslationService"

Server: TranslationService/3.5.0.0

Trace 3.2 – Progress Report (first packet)

The first Progress Report packet sent from Translation Service (Server: TranslationService/3.5.0.0) holds an interesting data in ms-diagnostics header carrying information about normalization rule used to translate dialed number (RuleName=”3test”), as well as dialed (CalledNumber=”3123456”) and translated number (TranslatedNumber=”+38535123456”).

101 Progress Report (2)

11/17/2009|18:22:39.154 E54:F68 INFO :: Data Received - 200.1.1.20:443 (To Local Address: 200.1.1.201:2389) 897 bytes:

11/17/2009|18:22:39.154 E54:F68 INFO :: SIP/2.0 101 Progress Report

ms-user-logon-data: RemoteUser

Authentication-Info: NTLM rspauth="01000000000000003A15F11FDB3F8BA6", srand="38D4C7E0", snum="11", opaque="5C3ADF72", qop="auth", targetname="R2EE01.uclab.org", realm="SIP Communications Service"

Content-Length: 0

Via: SIP/2.0/TLS 200.1.1.201:2389;ms-received-port=2389;ms-received-cid=4000

From: "Marino Filipovic"<sip:marinof@uclab.org>;tag=0c0ef918e6;epid=1488039028

To: <sip:3123456;phone-context=zagreb.uclab.org@uclab.org;user=phone>

Call-ID: bcd9cff8600c4b2487845f5ae211f7c6

CSeq: 2 INVITE

ms-diagnostics: 12006;reason="Trying next hop";source="R2EE01.uclab.org";PhoneUsage="CN={D6912478-0BBC-4A6B-83F6-01D79BD7E126},CN=Phone Route Usages,CN=RTC Service,CN=Services,CN=Configuration,DC=uclab,DC=org";PhoneRoute="National Calls";Gateway="R2MS01.uclab.org:5061";appName="OutboundRouting"

Server: OutboundRouting/3.5.0.0

Trace 3.3 – Progress Report (second packet)

The second Progress Report packet is sent from another server side application: Outbound Routing (Server: OutboundRouting/3.5.0.0). The number normalized by Translation Service (as explained in Trace 3.2) could not be matched to existing SIP URI, and thus the call has to be routed out of OCS environment via Med.Server/gateway using the National Calls route (PhoneRoute="National Calls";Gateway="R2MS01.uclab.org:5061"). Again, the choice of the route and appropriate gateway has come as a result of previously mentioned procedure (matching normalized number and caller’s Voice Policy phone usages to the number pattern and phone usages in available routes)

183 Session Progress

11/17/2009|18:22:39.435 E54:F68 INFO :: Data Received - 200.1.1.20:443 (To Local Address: 200.1.1.201:2389) 2678 bytes:

11/17/2009|18:22:39.435 E54:F68 INFO :: SIP/2.0 183 Session Progress

ms-user-logon-data: RemoteUser

Via: SIP/2.0/TLS 200.1.1.201:2389;ms-received-port=2389;ms-received-cid=4000

Authentication-Info: NTLM rspauth="0100000000000000A6E772DCDB3F8BA6", srand="60A1AF0C", snum="12", opaque="5C3ADF72", qop="auth", targetname="R2EE01.uclab.org", realm="SIP Communications Service"

FROM: "Marino Filipovic"<sip:marinof@uclab.org>;tag=0c0ef918e6;epid=1488039028

TO: <sip:3123456;phone-context=zagreb.uclab.org@uclab.org;user=phone>;tag=753a4cf29d;epid=B6EE6ACB83

CSEQ: 2 INVITE

CALL-ID: bcd9cff8600c4b2487845f5ae211f7c6

RECORD-ROUTE: <sip:pool01.uclab.org:5061;transport=tls;ms-fe=R2EE01.uclab.org;opaque=state:F;lr;received=172.31.255.222;ms-received-cid=4101>

CONTACT: <sip:R2MS01.uclab.org@uclab.org;gruu;opaque=srvr:MediationServer:XDQqnDzOpESpnFD0MajmKgAA>;isGateway

CONTENT-LENGTH: 1558

SUPPORTED: gruu-10

CONTENT-TYPE: application/sdp

ALLOW: UPDATE

REQUIRE: 100rel

SERVER: RTCC/3.5.0.0 MediationServer

Rseq: 1

Record-Route: <sip:sip.uclab.org:443;transport=tls;opaque=state:Ci.R4000;lr;ms-route-sig=halHDFb5tb_P1j5pyPPGNCZq-kEkaR3G_J0lwmrQAA>

v=0

o=- 0 0 IN IP4 172.31.255.223

s=session

c=IN IP4 172.31.255.223

b=CT:1000

t=0 0

m=audio 61508 RTP/SAVP 0 8 115 13 118 97 101

c=IN IP4 172.31.255.247

a=rtcp:60865

a=ice-ufrag:jrbL

a=ice-pwd:vmjJgl/BqZr0BfHdGG8+m5Lr

a=candidate:1 1 UDP 2130706431 172.31.255.247 61508 typ host

a=candidate:1 2 UDP 2130705918 172.31.255.247 60865 typ host

a=candidate:2 1 UDP 2130705919 172.31.255.223 63845 typ host

a=candidate:2 2 UDP 2130705406 172.31.255.223 63260 typ host

Trace 3.4 – Session Progress

Not much to comment in Session Progress packet, as it is also consistent with the previous packets in this scenario.

Since the normalized number has destination on PSTN, the Mediation server acts as ICE client and sends an SDP answer with its candidates back to originating client to negotiate the optimal media path. Again, for more information about firewall traversal of media, please refer to very detailed blog How Communicator Uses SDP and ICE To Establish a Media Channel created by Bernd Ott.

[1] SIP URIs can be found in several formats: sip:name@domain.com (basic SIP URI), sip:+12345678@domain.com (SIP URI with phone number), sip:name@1.2.3.4 (SIP URI with IP address) and several other formats.

[2] According to RFC 3261, initial Request URI is set to the value of URI in the To: field (except for REGISTER request).

[3] SIP session setup is a three-way handshake process – INVITE/OK/ACK for a success, or INVITE/4XX or 5xx or 6xx/ACK in case of a failure. INVITE is the only SIP method that is in a form of three way handshake, as all other SIP requests are in the form of Request/200 or Request/4xx or 5xx or 6xx for a failure. Several provisional responses (1xx) can be seen between INVITE and final 200 OK (Trying, Progress Report, Session Progress), and we’ll tackle these responses later through SIP traces.

[4] The From-tag parameter is assigned when the INVITE request is sent out while the To-tag is added by the remote party when answering INVITE request

[5] According to Early Media and Ringing Tone Generation in the Session Initiation Protocol , early media “refers to media (e.g., audio and video) that is exchanged before a particular session is accepted by the called user”.

[6] For more details on P-Preferred-Identity and P-Asserted-Identity headers, please see RFC 3325 - Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks

[7] ms-diagnostics header is added by SIP server to indicate an error and/or provide a troubleshooting information that can be helpful in resolving the error. Since values of this header can contain information that is private to the company, it should be removed when SIP responses are leaving the enterprise boundary.

[8] Lack of support for early media in previous client version could sometimes lead to initial greeting not being heard.

[9] Normally, the client itself will normalize the number immediately as user is typing the number in OC (as client receives all normalization rules through in-band provisioning process) but in rare cases (such as when new normalization rule is added and client still didn’t refresh the information), the server-side Translation Application will be involved, as in example above.

Remote Access Configuration Guide by Rick Varvel

ToninoF — Wed, 04 Nov 2009 17:52:08 GMT

Working with regional and worldwide customers and partners who deployed OCS 2007 or 2007 R2, it was noticeable that one area was particularly challenging to configure - remote access. Although official documentation was good and detailed, there was many different aspects to take care of, and which is more, it would involve several different teams to fully configure remote access: OCS, networking, and security/perimeter network teams. Apart from OCS aspects, configuring remote access involves firewall and reverse proxy configuration, choosing and deploying correct certificates, registering correct DNS records internally and externally, (optionally) configuring load balancer, etc, etc.

So, the only missing piece of puzzle was a whitepaper or a guide that would connect all these pieces together: something like the Notes From the Field. Exactly such kind of document was created by my colleague Rick Varvel who wrote an excellent white paper “OCS 2007 R1/R2 Remote Access Configuration Guide”. If you are about to deploy Edge servers for remote access and/or federation with your partnering company or PIC, I would highly recommend downloading (and studying, which is more important :) ) Rick’s whitepaper from: http://blogs.technet.com/rickva/archive/2009/04/09/ocs-2007-r1-r2-remote-access-configuration-guide.aspx

Office Communicator SIP Trace Analysis – Registration

ToninoF — Sat, 31 Oct 2009 18:24:35 GMT

When I changed my career path to Unified Communications a few years ago (after having spent two decades with several UNIX flavors, MS directory and MS messaging platforms), one of the biggest challenges for me was trying to understand what all those methods and headers in SIP protocol trace exactly meant.

In trying to decipher it’s meaning, especially when troubleshooting unsuccessful calls, it didn’t help that there was no abundance of helpful online information.

First huge help was the introduction of Snooper tool from Microsoft OCS 2007 Resource Kit Tools, as Snooper sorts related SIP messages and presents SIP methods and headers in very readable way, in contrast to plain text files you had to use for analysis before Snooper.

Having Snooper around and SIP protocol gaining on significance each day actually determined the first topic for my Unified Communications blog – understanding SIP traces. Once this was decided, why not start from the beginning – client registration itself.

In a series of Snooper screenshots that follow, we’ll go through the registration process when SIP client registers its address with SIP server. You will see two examples: Office Communicator user registering both from internal network, and from outside, as a remote user. You will also see that not every red message in Snooper immediately denotes an issue – in registration process it may be just a normal, expected message that fits in the expected registration flow.

Remote SIP client registration

So, let’s start with a remote client (sip:izabelaf@uclab.org) that initiates the login sequence by sending a REGISTER request.

Figure 1: The remote client sends a REGISTER request with no credential or authentication information.

The more detailed look at the first packet (Figure 1) will reveal that the client connects from its local address (200.1.1.201) to port 443 of Access Edge Server (200.1.1.20). In Office Communications Server 2007 R2, port 443 of Access Edge server is used for remote user access. Note that the Call-ID header will have the same value throughout the session - in this case it will be the same for all 6 messages from the beginning of registration process till its end.

In this first packet the client sends REGISTER request without any credentials, as suggested in RFC 3261.

Note: From: and To: header values in Register request will typically be the same, as From: header denotes the client responsible for registration, while To: header denotes the client whose registration is to be created. The only case those two fields can differ would be if the request is third-party registration. For more information on mandatory SIP header fields in SIP requests, please check RFC 3261 - SIP: Session Initiation Protocol

Figure 2: The server responds to the request with a 401, indicating that it supports NTLM and requires authentication.

Since authentication is enabled on the server, it sends 401 Unauthorized message to the client and indicates a support for NTLM authentication. Note that server added “ms-user-logon-data: RemoteUser” header to indicate that the client is logging in from outside of corporate network. This information also tells the client that it should use the web service URLs that are accessible from the Internet for distribution list expansion, address book download, and meeting content download [1] The RemoteUser info also tells the client that it does not have direct media connectivity to the enterprise network.

[1] The client will obtain all necessary information later in a 200 OK response to the SUBSCRIBE request for In-band Provisioning event (Event: vnd-microsoft-provisioning-v2)

Figure 3: The client reissues the request

Client reissues the request, now with Authorization header, confirming it supports NTLM authentication. The client calls the NTLM authentication protocol implementation with Izabela’s credentials (user name, domain, and password) and several other (Datagram, Identify, and Integrity) parameters to initialize the security context and generate (an empty) NEGOTIATE_MESSAGE. You can use one of network trace tools (NetMon, Wireshark) to obtain more data about actual NTLM messages exchange.

NTLM Background Information: There are two major flavors of NTLM auth protocol: connection-oriented and connectionless (datagram). In connection-oriented NTLM, negotiation starts with a NEGOTIATE_MESSAGE, carrying the client's preferences, and the server replies with NegotiateFlags in the subsequent CHALLENGE_MESSAGE. In connectionless (datagram) NTLM, however, the server starts the negotiation with the CHALLENGE_MESSAGE and the client replies with NegotiateFlags in the subsequent AUTHENTICATE_MESSAGE.

In our example above, the client picked Datagram option, and that is the reason an empty NEGOTIATE_MESSAGE is sent.

Figure 4: The server responds with 401 sending an appropriate challenge in WWW-Authenticate SIP header

After receiving client’s reissued REGISTER request, the server calls its NTLM security subsystem which processes empty NEGOTIATE_MESSAGE and generates NTLM CHALLENGE_MESSAGE which it sends to the client (gssapi-data parameter carrying the challenge in WWW-Authenticate header) in another 401 Unauthorized message (Figure 4).

Figure 5: The client responds to the server's challenge.

Client now reissues the REGISTER request with the response to the server’s challenge (Figure 5).

The process of generating response to server’s challenge (simplified due to clarity) starts with client first having to decode base64-encoded content of gssapi-data parameter and passing the challenge to its NTLM subsystem that in turn generates AUTHENTICATE-MESSAGE. Gssapi-data parameter (sent in Proxy-Authorization header) thus carries client’s response to server challenge proving that the client knows the password.

Figure 6: The server processes the request and responds (including its signature for the response) with Authentication-Info.

The server finds out the client identity from the request and the "opaque" value from the authorization header field received in previous REGISTER request (Figure 5), and calls its NTLM subsystem to process AUTHENTICATE_MESSAGE. The NTLM subsystem authenticates the client and validates that the user is authorized to use the "izabelaf@uclab.org" SIP URI. The server continues processing the REGISTER request (as described in RFC3261) and passes it to the SIP Registrar component which (after it completes processing) sends back a "200" response to the client (Figure 6).

Internal SIP client registration

Let’s see now what happens with internal client (sip:marinof@uclab.org) issuing REGISTER request:

Figure 7: The client sends a REGISTER request with no credential or authentication information.

As you can see in Figure 7 showing the first REGISTER attempt for internal user, the client connects from its local address (172.31.255.247) to port 5061 of his home pool (172.31.255.222). Again, no credentials or authentication information is sent to the server.

Figure 8: The server responds with "401"

Figure 8 shows server sending 401 Unauthorized to the client, also stating its support for both Kerberos and NTLM authentication methods (WWW-Authenticate headers). Please note the difference in targetname parameter values between Kerberos and NTLM responses: The targetname parameter for Kerberos contains the SPN for Marino’s home server, while the targetname for NTLM carries the FQDN of home server.

Note: For Kerberos, the targetname value must be prefixed with a "sip/" service descriptor and the server must register its targetname value with the KDC database. If the server supports both the NTLM and Kerberos protocols, the targetname value in NTLM must be the same as the targetname value in Kerberos without the "sip/" service descriptor.

Figure 9: The client chooses Kerberos protocol and reissues REGISTER request to the home server

What is not visible from the SIP trace[2] is that client obtained a Kerberos ticket for the server (in KRB_TGS_REP message from Ticket Granting Service – see Kerberos background information (1)). The client included this information in the gssapi-data parameter of the Proxy-Authorization header:

Proxy-Authorization: Kerberos qop=”auth”, realm =”SIP Communications Service”,

targetname=”sip/R2EE01.uclab.org”, version=4, gssapi-data”=”YIIE…”

The Proxy-Authorization: header above (and in more details in Figure 9) shows that client opts for Kerberos auth (Proxy-Authorization: Kerberos) and reissues the REGISTER requests to his home server identified by an SPN in targetname parameter (sip/R2EE01.uclab.org).

Please, also note the response parameter in Proxy-Authorization header – the value of this parameter carries the client signature, while analogous parameter on the server side is rspauth which carries the server signature (it can be found in Proxy-Authentication-Info header in servers response – Figure 10).

[2] The entire Kerberos ticket request/response message flow can be seen using a NetMon or Wireshark network trace

Figure 10: The server processes the request and responds

Marino’s home server received the REGISTER request, verified the Kerberos ticket (see Kerberos Background Information (2)) and successfully processed the REGISTER request.

Kerberos vs NTLM Background info

Although the Kerberos vs. NTLM title may sound a bit pompous, as it’s not easy to compare these two protocols in just a few words, I’ll try to address just those most obvious differences that are important for our topic.

Office Communications Server 2007 R2 supports two authentication mechanisms when it comes to client-to-server authentication and mutual message signing: Kerberos and NTLM. While Kerberos is standard and a more secure protocol, there are situations where NTLM has to be used.

An example is when remote user (not having connectivity to the Domain Controller) tries to register to its home pool. With Kerberos, the client must request Kerberos ticket from the KDC (Key Distribution Center), which, in Microsoft implementation, resides on the domain controller (see Kerberos Background Information (3).

Although you can find some background info below, a full Kerberos authentication details are not in the scope of this blog, so to make the long story short – with Kerberos auth, client have to have access to Domain Controller to be able to authenticate which is not the case with remote clients (I am not discussing the clients connected through VPN, but “real” remote clients accessing their OCS infrastructure by means of Edge servers).

NTLM is a bit more benevolent when it comes to authenticating remote users. With NTLM, the client doesn’t have to directly contact DC, but the server verifies the client's credentials by contacting the domain controller. This NTLM’s approach to authentication allows clients that do not have connectivity to the domain controller to authenticate with the server using NTLM authentication. This is also the main reason for supporting NTLM, in addition to the more secure and standard Kerberos authentication.

Kerberos background information (1)

For more details on Kerberos message flow, please take a look at How the Kerberos Version 5 Authentication Protocol Works and particularly RFC 4120 - The Kerberos Network Authentication Service (V5) . I will provide just a short overview of the process that should be sufficient for the blog topic.

In a nutshell, there are three types of ticket exchanges with six messages exchanged:

· Authentication Service Exchange: KRB_AS_REQ and KRB_AS_REP

· Ticket Granting Service Exchange: KRB_TGS_REQ and KRB_TGS_REP

· Client/Server Exchange: KRB_AP_REQ and KRB_AP_REP

A little more details on each of these messages:

KRB_AS_REQ

As its name implies, the client contacts KDC’s Authentication Service (residing on Domain Controller) with request to obtain a TGT. Client will use TGT every time when it requests a service ticket to access a service or application on the server. Without TGT, client would have to enter password each time it requests a service ticket, and this way it enters password only during logon. So, in this first KRB_AS_REQ message, client sends username and user’s domainname in clear text, together with Pre-authenticator (e.g. machine timestamp encrypted with user’s password hash)

KRB_AS_REP

if AS can decrypt Pre-authenticator (which would prove that client knows the proper password), it will create a session ticket with session key for client-to-KDC communication, as well as a TGT (readable only by KDC) which contains client authorization data. The client will use obtained session key to encrypt further communication with TGS, for example, to encrypt Authenticator (usually contains client ID and client machine’s timestamp) that it will present to Ticket Granting Service (together with TGT) when requesting service ticket.

KRB_TGS_REQ

When client needs access to network (or even local computer) resources it will send a request to TGS for the service ticket. To get the service ticket, client will present TGT (obtained in KRB_AS_REP), an Authenticator and the name of target server (in a form of Service Principal Name, or SPN). If TGS can decrypt authenticator using the session key known only to client and KDC, it would prove that client is the one who it claims to be (in any case, it’s someone who knows the correct session key :). Just to shortly discuss this smiley – although Kerberos is secure protocol, password policy is critical here, as with very weak password, brute force attack can be successful in decrypting pre-authenticator mentioned in KRB_AS_REQ. In that case, all further steps could be compromised, so please, pay attention to complex passwords that are long enough and combination of lowercase, uppercase, non-alphanumeric characters, and digits.

KRB_TGS_REP

The Ticket Granting Service will examine the TGT and authenticator and if both are acceptable, TGS will create a service ticket. Apart from service ticket (that only server can decrypt), TGS will send a session key for client/server encrypted communication. I didn’t mention so far that TGT (which is btw, encrypted with krbtgt account’s password hash) contains user’s (security principal’s) authorization information in a field called PAC (Privilege Attribute Certificate). The content of PAC (group membership of security principal requesting access) is copied to service ticket and will be used later to construct access token for the client.

KRB_AP_REQ

As soon as client needs to access the server/service, it will send the service ticket to the server as well as Authenticator (client ID and machine timestamp encrypted with client/server session key). When server obtains the service ticket, it will decrypt it (using the key known only to server and KDC), extract its own copy of the client/server session key, use this session key to verify authenticator and if everything is ok, it will create an access token for the user based on SIDs found in service ticket.

KRB_AP_REP

The last message actually is optional, and is used if client requested mutual authentication. The server will use its copy of client/server key to encrypt (modified) authenticator and send it back to the client. It’s necessary to modify and re-encrypt the authenticator to prove that authenticator is not just replay attempt.

Please note that this is just very condensed information about Kerberos ticket exchange and I would suggest to refer to RFC 4120 - The Kerberos Network Authentication Service (V5) each time you need detailed information about all Kerberos aspects.

Kerberos background information (2)

When client request any service from the server, one of the messages it sends to the server (in KRB_AP_REQ request) is an Authenticator – it can simply be a Client ID and client machine’s timestamp encrypted with the key only client and server know. The client obtained this client/server key in earlier, KRB_TGS_REP exchange from Ticket Granting Service. Apart from client/server key that client could decrypt, TGS also sent service ticket (that contains the same client/server key) that only server can decrypt. The server will use server/KDC key to decrypt the service ticket, extract client/server key, use it to decrypt Authenticator and thus verify that client is who he claims to be. The last step would be for server to modify authenticator, encrypt it with client/server key and send back to client for mutual authentication (as described in KRB_AP_REP) above.

Kerberos background information (3)

Again, the whole story is a bit more complex, as client first needs to obtain a ticket to access Ticket Granting Service on KDC, by contacting Kerberos Authentication Service first, as described in Kerberos background information (1)