It's enough to be on your way...

What The?????? Exchange 2007 and Windows Server 2008 Backup

noreply@blogger.com (Ryan Newington) — Wed, 13 Feb 2008 11:28:00 +0000

<rant>

Ok, I'm in a bit of shock. I normally only have nice things to say about Microsoft and their products, and I've always stood behind them 100%. But I'm upset today, so I'm going to have a bit of a rant and explain why...

I've been planning my migration from Windows Server 2003 to Windows Server 2008 which was released last week. On my test machine, I got Exchange 2007 SP1 installed and configured no problems. Just before I was about to change the production system over, I thought "it's probably a good idea to test the backup", since I remember seeing something about a new backup system in Windows Server 2008.

Before I go on, I should outline my current backup arrangements. I currently use NTBackup on Windows Server 2003 to backup my server and Exchange Mailboxes. I don't backup everything, as I have a large amount of data that I don't really care about (several TBs), so I select the important things I need to backup like programs, personal folders, and system files and settings. I backup to a local 2TB array on my system. Its not an unusual setup, and certainly not a complex arrangement. Most importantly it does exactly what I need it to.

So... I fire up the new Windows Server Backup console and get ready to configure my backup jobs. The first problem I noticed was it gave me 2 options.

Option 1: Full Server (recommended) - I want to back up all my server data, applications, and system state

Well, thank you mister wizard, but no, I don't want to back all that up, what other options do we have?

Option 2: Custom - I want to exclude some volumes from this backup.

Erm... well I want to exclude some files and folders, not an entire volume, what other options do we have?

(insert deafening silence here)

That's it! They were my options. Surely not! After a bit of research, I find that there is a command line tool wbadmin.exe that allows a few more options than the GUI (I have a real problem with this move away from the GUI back to the command line - if I wanted to spend my life at a command prompt, I'd become a linux sysadmin... this isn't what I signed up for - but that's a post for other day). Perhaps I can specify a config file of some sort to tell it exactly what I want backed up? Searching through the rather pitiful documentation on Technet reveals that its actually as useless to me as the GUI. There is simply no support for backing up individual files or folders.

So ok, maybe I could shuffle some data around the various volumes and work around this inconvenience. Lets test a backup and see what the Exchange restore process is like. The backup was relatively fast, and I proceeded to use the wizard to walk me through the recovery process. I was presented with the following options

Errrm... Applications appears to be disabled. Did Exchange get backed up? I opened up the mailbox store folder to see if the transactions logs have cleared as they do after a successful full backup. Nope... still there... how bizzare! Time to do some research.

I came across this post, at which point, I was ready to cry. No support for Exchange at all with Windows Server Backup. No support for backing up individual files or folders. Further research reveals that even the ability to backup to tape has been removed from Windows Server Backup. I can't see anything that relates to differential or incremental backups either. I could not agree more with Elan that Windows Server Backup is complete garbage.

To add insult to injury, I went looking for a copy of System Centre Data Protection Manager 2007 (which is supposed to support Windows Server 2008 and Exchange 2007) on the Technet Plus Subscription Site. All that was there was a copy of DPM beta 2 from mid last year.

So I've now shut down my Windows Server 2008 test box. I've thrown my toys out of the sandpit for now. I know a lot of people that complain about NTBackup, and it was less than ideal in a lot of respects, but it came with the OS and it got the job done. Now, it has been replaced by something that is 100% useless. How on earth did this get approved as the backup solution to be released with Microsoft's latest and greatest server OS? Who in their right minds thought "Wow, what a quality piece of software. Lets approve this for release!"?

Get your act together Microsoft... this is a joke.

</rant>

Interim information on integration OCS and Asterisk

noreply@blogger.com (Ryan Newington) — Mon, 17 Dec 2007 08:05:00 +0000

Disclaimer: This guide hasn't been tested and verified like the Exchange UM guide - it may not be 100% accurate. It is not a step-by-step detailed and assumes you know your way around trixbox, sipX and OCS, or at least have configured Exchange UM using my guide. It is provided only for early adopters that want to experiment in a test environment. It WILL NOT work with the trixbox version (2.2) used in the Exchange UM guide. See my post here on issues with Asterisk and OCS integration FIRST. Please feel free to provide comments, feedback and results of your own testing (via email please).

Overview: In order to make this work, we need to install the follow-me module in Asterisk, define a custom voicemail macro for follow-me, and configure some new dial rules in sipx. I use a single extension range (400-499), and use sipx to do some fancy number transformations to allow calls to flow back and forth correctly.

Step 1: Install the folllow-me module in freePBX.

Step 2: Edit extensions_custom.conf and add the following code;

[custom-exchangevm]
exten => s,1,NoOp(Entering custom-exchangevm for a call to ${DNID})
exten => s,n,Set(EXTTOCALL=${BLKVM_BASE})
exten => s,n,NoOp(Sending to Voicemail box ${EXTTOCALL})
exten => s,n,SIPAddHeader(Diversion: <tel:${EXTTOCALL}>\;reason=no-answer\;screen=no\;privacy=off)
exten => s,n,Dial(SIP/222@sipx.lithnet.local|30)

Step 3: Configure follow-me for your extensions. The extension list should contain both the extension number, and the extension number followed by a numerical prefix. I used the number 4. You can use whatever you want, as long as you can route it in your dial plan - adapt this guide as appropriate. Make sure the the external numbers are followed by '#' so the module knows it needs to route outside of asterisk. Select 'Custom app' for the no answer destination, and type custom-exchangevm,s,1 in the text box.

Step 4. Configure an outbound route. You can either create a new route to send 4xxx calls to sipx, or add 4xxx to your existing sipx route as shown below.

Step 5. Now we need to configure sipX to strip off the prefix ('4') we added, and replace it with a plus sign (+). OCS requires that numbers be in E164 format, I'm not going to go into that in detail, but for testing purposes, we can just add a + at the start of the number, and it will be happy.

Add the following to your /etc/sipxpbx/external_mappingrules.xml file.

<userMatch>
      <userPattern>4xxx</userPattern>
      <permissionMatch>
        <transform>
          <user>+{vdigits}</user>
          <host>ocs-med.lithnet.local</host>
          <urlparams>transport=tcp</urlparams>
          <fieldparams>q=0.9</fieldparams>
        </transform>
      </permissionMatch>
    </userMatch>

Add this to your external_authrules.xml file:

<hostMatch>
    
    <hostPattern>ocs-med.lithnet.local</hostPattern>
    <hostPattern>192.168.0.80</hostPattern>
    <hostPattern>ocs-main.lithnet.local</hostPattern>
    <hostPattern>192.168.0.70</hostPattern>
    <userMatch>
      <userPattern>.</userPattern>
      <permissionMatch/>
    </userMatch>
</hostMatch>

Step 6: In the sipx web interface, add a new dial rule called OCS-Asterisk Dial Rule. In the dialed number field, put + as the prefix, and select ‘3 digits’ (or however many digits you have in your extension). Leave all the ‘required permissions’ unticked. In resulting call, leave the prefix blank, and select ‘variable part of dialed number’. Select Asterisk as your gateway. Activate your dial plans and you are done.

Step 7: In the OCS Management console, right click on your mediation server, and click properties. Type the IP Address of your sipX server as the next hop destination.

Step 8: Configure users for PBX integration. Note the "+" before the number.

Step 9: Add an outbound route in OCS by right clicking on your forest in the OCS Management Console, selecting 'Voice Properties', clicking on the 'Routes' tab, clicking 'Add', and entering the information shown below. The regular expression basically says to route all calls to numbers beginning with a + to the Mediation Server.

Step 10: Add normalization rules. Back on the Voice Properties tab, click Location profiles and add a new profile. Add a new normalization rule. Use the information below to create a basic normalization rule. This example will take any 3 digit number starting with '4', and append a + sign to it. This gives us a number that is formatted and can understood by the dial rule we set up in step 9.

That should be it. Add other normalization and dial rules as required to accommodate your needs. OCS uses SIP/TLS for encrypted communication between OCS servers and clients by default. If you run into difficulties and need to troubleshoot, turn off TLS and you will be able to see the SIP packets, rather than encrypted TCP traffic.

Once again, I stress that this is not a complete guide. Just something to get started with, as many people have been asking for this. Please contact me via email if there are any errors you come across in this post.

OCS/Asterisk integration Update

noreply@blogger.com (Ryan Newington) — Mon, 17 Dec 2007 08:02:00 +0000

Many people have been eager to find out what is going on with the Asterisk and OCS integration guide. First, let me say I haven't forgotten about it! There are a few problems that myself and others who are working on this with me are trying to resolve.

As it stands, OCS and Asterisk don't want to play nice together. Each product seems to have a unique bug in it, that unfortunately only shows up in combination with the other. I'll give you a short explanation of each problem. If you haven't already done so, I recommend you read up on SIP and RTP, otherwise this probably wont make any sense to you.

The OCS bug

The first RTP packet sent by the OCS mediation server is completely broken. There are two problems with this packet

1. The packet is being sent to UDP port 0, not the port defined in the SIP Session description (SIP/SD) packet. Port 0 is a reserved port, and should never be used. The remote host correctly responds with an ICMP destination port unreachable message.

2. The second problem with the packet, is that it is sent to the SIP gateway, not the RTP endpoint specified in the SIP/SD packet. So even if the packet was sent to the correct port, its being sent to the wrong host. In our setup, the Mediation Server is sending this RTP packet to port 0 of the sipX server. It should be going to the RTP port of the Asterisk server.

Initial RTP packet sent by the OCS Mediation server to port 0

Now, as far as I can tell, this happens even with the 'OCS approved' gateway products. I reviewed some SIP traces of communication with a Dialogic gateway, and saw the same behaviour. Subsequent RTP packets appear to travel to the correct destination server and port, and other gateways ignore and compensate for the bad/missing packet. This is where Asterisk's bug comes into play

The Asterisk bug

Now, as we all know, UDP is a stateless protocol, that does not guarantee reliability or delivery as TCP does. Packets may arrive out of order, or go missing completely. As VoIP is time-sensitive, we use UDP for the audio data, because we would rather some packets go missing, than all of the arrive, but possibly be delayed. So a UDP implementation must never rely on the delivery of a UDP packet.

From my own behavioural observations (and I could be wrong), it seems the Asterisk uses the initial RTP packet as a 'trigger' to start proxying the RTP traffic it receives from both endpoints. This first RTP packet is used to inform the other endpoint that it is about to start receiving data, but it never contains audio data (as shown in diagram above). As this packet never arrives, Asterisk just seems to wait indefinitely, ignoring all subsequent RTP packets from the mediation server, and our SIP phone. Given that there is no guarantee of receiving this packet, Asterisk should not be waiting for it, and should proceed with the correctly formed RTP packets it receives from the OCS Mediation Server.

The good news

There have been some reports of success with the newer build of Asterisk that comes with the new beta version of trixbox. I have not personally tried this, and coming up to Christmas, I'm not sure I will get time to until the new year. However, for those that do not want to wait, here is a post with some bits and pieces to get you started.

OCS/Asterisk integration work in progress

noreply@blogger.com (Ryan Newington) — Mon, 29 Oct 2007 08:14:00 +0000

UPDATE 17/12/2007: This information has been superseded by a more detailed post.

So I have finally gotten my act together and started my OCS/Asterisk integration. For those of you that don't want to wait for the full guide, you can start by configuring your dial plans in Asterisk and sipX to point to your mediation server. Add the following code into extensions_custom.conf

You will need to install the "Follow me" module in FreePBX. Then configure the follow me settings for each extension as shown so that both the Asterisk extension and the OCS phone ring at the same time. Note for each number that is external to the Asterisk system, you must append a hash (#) to the end of the number as shown below for 800 - my OCS extension.

More to come.

Microsoft Unified Communications Australian Launch Events

noreply@blogger.com (Ryan Newington) — Mon, 29 Oct 2007 07:52:00 +0000

If your in Melbourne or Sydney in November, the I highly recommend that you come along to the Microsoft UC product launch. I've booked in for the following sessions;

Office Communications Server 2007 Deployment

This demonstration will walk through deployment of Office Communications Server 2007 (OCS 2007) starting with the planning & deployment guide, standard edition installation, user provisioning and entitlement, configuration, and finally validation. OCS 2007 will be the main emphasis of this demonstration. This session can be broken down into three parts. In the first part of the demonstration, we show the easy setup of Standard Edition 2007, which allows an organisation to provide IM, peer to peer voice call capabilities immediately. The second part of the session will include an overview of complex installation topologies recommended for OCS 2007, including considerations for Enterprise Edition deployment, Edge server roles, various MCU roles, Mediation server and the Archiving server role. The third part of the session focuses on federation and public internet connectivity features of OCS 2007. This includes setup of Edge server roles for Public Internet Connectivity and Federation capabilities. It will also cover integration with Exchange Server 2007 SP1 Unified Messaging which enables an exciting set of features for end-users.

Exchange Server 2007 SP1 Overview

This demonstration will walk through the feature enhancements introduced in Exchange Server 2007 SP1. The demo will cover a range of new technologies, from Windows Server 2008, Standby Continuous Replication and Outlook Web Access 2007, to enhanced functionalities such as Mobility, end user experience and administrator management.

Unified Communications Journey, A real customers experience

HP began deploying Exchange Server 2007 and Office Communications Server 2007 in live internal and customer environments long before these products came to market. In this session you will hear about the trials, tribulations and ultimate success of implementing a consolidated Exchange Server 2007 environment across multiple geographies, complete with Unified Messaging and then Office Communications Server 2007 integrated with Cisco Call Manager. Understand the business objectives and requirements that lead to this implementation including the unexpected benefits as highlighted in the case study. Learn from our mistakes, understand the real value, and pre-requisites for full functionality and ultimately streamline your own deployment!

Mobility & Anywhere Access

This presentation will demonstrate the benefits of remote access and mobility features for Office Communicators Server 2007 and Exchange Server 2007. The scenario will focus on how users stay connected and can work without interruption while travelling and on the go. Users continue to have access to presence and contact information and choice of communication options including mail, instant messaging, voice and multi-party conferencing. They can view documents and access Microsoft Office SharePoint sites remotely. All these features increase productivity for the organisation and are easy to set up by IT professionals. We will talk about implicit benefits of cost saving and lower help-desk calls.

Use the following links to register. It's a free event. Send me an email if you are coming!

Make sure you check out the new Australian UC product site, and if you haven't already subscribed to Johann's Unified Communications blog, do it now!

Enabling outbound calls from Exchange UM (OVA) to the PSTN using Asterisk

noreply@blogger.com (Ryan Newington) — Sat, 27 Oct 2007 00:15:00 +0000

One of the great features of Outlook Voice Access is the ability to lookup a person in the directory or your personal contacts list and have OVA connect you to that person. This obviously requires support some form of connection to the PSTN. The guide will take you through the steps of configuring the systems to allow OVA to make calls to the PSTN.

A big thanks to Sander de Rijk who provided the basis of these instructions earlier this year.

This guide assumes you have configured Asterisk to connect to your PSTN provider. If not, see my earlier post, then come back when your done.

The first thing you need to do is decide if you want to configure an 'outside line' access code. The most common numbers used for access to the trunk are 0 and 9. However, its becoming increasingly popular not to use such a code, and configure appropriate rules in the various dial plans instead. The following instructions will be based on NOT using a trunk access code, but adding this functionality is very straightforward.

Open the Exchange Management Console, and in the left hand pane, select Organization Configuration, Unified Messaging. Right click on your dial plan, and select Properties. On the Dial Codes tab, enter the dial codes relevant to your location. This can be a little confusing, but the Help button will reveal some information that can guide you through this process. Note that all this information is optional, and if you are only have one dial plan, and are going to making calls within our country/region, you can leave all the fields on this tab blank.

Next, click on the Dialing Rule Groups tab, and add a new In-Country/Region Rule. Give your rule a name, and enter a number mask. In my example below, I take a local 8 digit phone number, and add my state's extension (03) to it.

If I have a number in my contacts or directory that contains the country code (61 for Australia), this rule will remove it, and replace it with a 0 which is used for In-Country dialing.

Continue adding rules for your numbers as required, unfortunately I can't include all the various country and region codes in this guide, but I'm sure you will work them out without too much trouble. Once completed, you should have a list similar to that below.

That completes the Exchange portion of this configuration. Now we need to configure the appropriate rules on the sipX server. Visit the sipXconfig web site, and open the Asterisk dial plan (System->Dial plans->AsteriskDialPlan). Add the dial rules required for your area. If you configured an outside line access number, then you can simply enter that number as the prefix, and select "Any number of digits" from the drop down list.

Save the dial plan, and click Activate above the list of dial plans. Finally, we need to configure the route in Asterisk to send these calls through our PSTN provider. Visit the asterisk configuration page, and from within FreePBX, select Outbound Routes from the left menu. If you have already configured a route to the PSTN, then use that, otherwise add a new route. Add your dial patterns, and select the trunk you configured for your PSTN provider, and save.

Note that I have used different dial patterns on the sipX and Asterisk server. This is just to demonstrate the various ways you can go about configuring these systems. Both sets of rules work and are valid. You can choose less specific rules to make administration easier, or you might need more control over where your calls go (i.e certain calls need to be routed over a specific trunk). All are valid - adjust as needed for your requirements.

Apply your changes to the server, and you are done!

Woo!!!! Got my new phone - the HP iPAQ 512...

noreply@blogger.com (Ryan Newington) — Mon, 22 Oct 2007 10:46:00 +0000

For the better part of a year now I have been searching for a new phone. While my Nokia 6230 has served me very well over the years, it was time to upgrade to something with support for Exchange. I've had PDAs and PDA phones in the past, but have always found them too big and awkward to use as a phone. The stylus is annoying, and they have a habit of getting lost.

Earlier in the year, I finally found a phone that would do what I wanted. The HP iPAQ 510 looked very promising. It was to be their first smart phone. Alas, after a few months of waiting, our HP distributors informed me that there would be no iPAQ 510 for the Australian market. I was crushed.

A couple of months ago, I found out that a revision of the 510 - the 512 would be available here, but not until the first half of 2008 *groans*. Being the impatient person that I am, I wasn't prepared to wait until then, so after a few bidding wars on eBay, I secured a new 512 from overseas.

I have to say... this phone ROCKS. The feature set is amazing, and with Windows Mobile 6, Microsoft has finally got the whole phone interface sorted out. I always found WM 2003 and WM5 to be a less-than-average phone OS. Some new features of WM6 include;

Built in Windows Update
VoIP Support
Windows Live Messenger
HTML Email
OOF Support
Follow up flags for emails (FINALLY)
Better navigation and shortcuts
New versions of Office Mobile

The iPAQ has a built in SIP client, so it integrates perfectly with my ExchangeUM/Asterisk setup. As soon as it connects to a wireless network, the SIP client fires up and logs onto the Asterisk server, ready to receive calls. Additionally, Microsoft recently released Office Communicator Mobile 2007 so whenever I have a wireless connection, I am also connected to my OCS server.

The phone comes with HP Voice Commander software that you can use to give instructions to the phone. You can say things like

"Call Ryan at Home"
"Start File Manager"
"Read Email"
"What time is it?"
"Play <Song Name>"

A feature that I really like is the "Automatic" profile that automatically switches the phone to vibrate mode during an appointment marked as "Busy" in your calendar. I'm not sure if its been available in previous versions, but its the first time I have noticed it.

sipX 3.8 Released - Exchange UM Guide updated

noreply@blogger.com (Ryan Newington) — Mon, 22 Oct 2007 10:25:00 +0000

sipX 3.8 was released last week, and as such I have updated the Exchange UM guide with instructions on setting up version 3.8. This resolves the random timeout issue in version 3.6 that I described in an earlier post.

The VM that we used previously was quite old. It was based on Centos 4 and sipX 3.0, and contained a lot of other useless junk.

In the new instructions we use a bare-bones Centos 5 Virtual Machine, and install sipX 3.8 ourselves. This results in a faster more efficient VM.

Because the last VM was so dodgy, I'm not going to provide instructions for upgrading your old 3.0/3.6 servers to 3.8. You can perform a yum update if you really want, but I strongly recommend dropping that old VM and starting again. It will only take a short amount of time, and will be well worth it in the long run.

If anyone has had any experience with the SIP/TCP patch for Asterisk, please get in contact with me. I would like to hear about your results.

Accessing Exchange 2007 Unified Messaging: Part 4 – Configure the sipX Server (sipX 3.8/Centos 5)

noreply@blogger.com (Ryan Newington) — Mon, 22 Oct 2007 10:00:00 +0000

--------------------------------------
Update: 22/10/2007 - Replaced the old post with instructions for a new Centos 5 VM and sipX 3.8
--------------------------------------

Initial Configuration

Download the Centos 5 Minimal Installation VMware Appliance from the VMWare Appliance Marketplace.

Start your sipX VMWare virtual machine. Log in as root, with the password password and change the password by typing passwd at the command line. Type netconfig, and select Configure and assign a fixed manual IP address to this PC.

Now we need to set the hostname for this server. Use the nano editor to edit the network configuration file, and change HOSTNAME to sipX.lithnet.local. When done, press Ctrl-X, then Y, then enter to save the file.

nano /etc/sysconfig/network

In order for sipX to install, we need to disable SELinux. Edit the SELinux config file by typing nano /etc/selinux/config and change SELINUX=ENABLED to SELINUX=DISABLED.

Run the following commands in this order, and to all the Windows kids like me, remember that Linux is case sensitive, so take note of the uppercase X in the URL below (yes I stuffed it up myself and it took me about 20 minutes to work out why it was failing – silly muppet).

wget -P /etc/yum.repos.d/ http://sipxecs.sipfoundry.org/pub/sipXecs/sipxecs-stable-centos.repo
yum -y install sipxpbx sipxconfig sipxproxy sipxregistry

(If you want to use sipx as the main PBX (without using Asterisk - not recommended), then install additional modules as required as specified on the sipfoundry web site)

Now we need to fix the SSL certificates. If you have a CA on your network, you can have it generate a certificate for these purposes. Otherwise, we can just generate a self signed certificate using the following commands.

/usr/bin/ssl-cert/gen-ssl-keys.sh

This will prompt you for several pieces of information. Enter the appropriate information, and the following values when prompted.

CA Common Name: SelfSigned
SIP domain name: lithnet.local - The domain name of your installation
Full DNS name for the server: sipx.lithnet.local - Enter fully qualified hostname of your sipX server
Type the following to install the certificate.

/usr/bin/ssl-cert/install-cert.sh sipx.lithnet.local

Now we need to configure the Exchange gateway and rules. Normally, this XML is generated automatically by the web interface as we modify the gateway and dial plan options. We have to do this manually, because the web interface doesn't provide us a way to force sipX to use TCP for a particular gateway. If we configure our dial plans through the web interface, sipX tries to contact Exchange first using UDP, which more often than not results in a timed-out call. The sipX team is working to more natively support Exchange configuration through the web interface in the future. I will keep you posted.

At the sipx command prompt, type

wget -P /etc/sipxpbx/ http://lithiumblue.com/config/external_mappingrules.xml

to download the preconfigured mappingrules file needed to force TCP communication with Exchange. Type nano /etc/sipxpbx/external_mappingrules.xml to modify the file and replace the hostname values as shown below with your own. If for some reason you cannot download the file with wget, you can type it out manually as it appears below.

<?xml version="1.0" encoding="UTF-8"?>
<mappings xmlns="http://www.sipfoundry.org/sipX/schema/xml/urlmap-00-00">
<hostMatch>
<hostPattern>${SIPXCHANGE_DOMAIN_NAME}</hostPattern>
<hostPattern>${MY_FULL_HOSTNAME}</hostPattern>
<hostPattern>${MY_HOSTNAME}</hostPattern>
<hostPattern>${MY_IP_ADDR}</hostPattern>
<userMatch>

<userPattern>2xx</userPattern>
<permissionMatch>
<transform>
<host>dc1.lithnet.local</host>
<urlparams>transport=tcp</urlparams>
<fieldparams>q=0.9</fieldparams>
</transform>
</permissionMatch>
</userMatch>
<userMatch>


<userPattern>3xx</userPattern>
<permissionMatch>
<permission>Voicemail</permission>
<transform>
<user>222</user>
<host>dc1.lithnet.local</host>
<urlparams>transport=tcp</urlparams>
<headerparams>Diversion=<tel:{digits}>;reason=no-answer;screen=no;privacy=off</headerparams>
<fieldparams>q=0.9</fieldparams>
</transform>
</permissionMatch>
</userMatch>
</hostMatch>
</mappings>

The above rule ensures that calls for 2xx are sent to the Exchange server, and that sipX only communicates with it using SIP/TCP. It also enables diversion to Voicemail for calls to the sipX extensions (3xx). This is independent of the procedure to setup Trixbox/Asterisk to divert to voicemail. The sipX and Asterisk diversion configurations are completely independent of each other.

Now we need to tell sipX that it is responsible for routing calls to 2xx. Without this the calls would be rejected. At the sipx command prompt, type

wget -P /etc/sipxpbx/ http://lithiumblue.com/config/external_authrules.xml

to download the preconfigured authrules file. Type nano /etc/sipxpbx/external_authrules.xml to modify the hostname in this file.

<?xml version="1.0" encoding="UTF-8"?>
<mappings xmlns="http://www.sipfoundry.org/sipX/schema/xml/urlauth-00-00">
<hostMatch>

<hostPattern>dc1.lithnet.local</hostPattern>
<userMatch>
<userPattern>2xx</userPattern>
<permissionMatch/>
</userMatch>
</hostMatch>
</mappings>

In order for sipX to use these files we created, we need to add some lines into the config file. Type nano /etc/sipxpbx/sipxconfig.properties.in, scroll through the file, and locate the following lines or add them to the end of the file.
mappingRules.externalRulesFileName=/etc/sipxpbx/external_mappingrules.xml authRules.externalRulesFileName=/etc/sipxpbx/external_authrules.xml
Restart the server using the following command

reboot

After the server reboots, open your browser and navigate to the sipX server i.e. http://sipx.lithnet.local.

NOTE: There is approximately a 2 minute delay between the sipX services starting and being available. If you get an error message when loading the page, wait 2 minutes and try again.

If all goes well, you should be presented with an SSL certificate warning (if you used a self signed certificate). Accept this warning, and when prompted, enter a new PIN for the superadmin account. You will use this to log into sipXconfig on the next screen.

Gateway Configuration

Now we need to add a gateway to allow sipX to communicate with the Exchange Server. Click Devices on the top menu, Gateways, and select SIP Trunk from the Add New Gateway drop down list. Type the following information and press OK.

Name: ExchangeUMServer
Address: dc1.lithnet.local

Now we need to add another SIP trunk for the Asterisk server. Type the following information and press OK.

Name: AsteriskServer
Address: asterisk.lithnet.local

Dial Plans

Now we need to configure the dial plan. Dial rules are used to route incoming calls to the appropriate gateway. Click System on the top menu, followed by Dial Plans. In the Add New Rule drop down box, select Custom as our dialing rule type. Enter the following information and press OK.
Tick the Enabled box
Name: AsteriskDialRule
Description: Forward calls for 4xx-5xx to the Asterisk Server
Dialed Number, prefix: 4, and select 2 digits from the drop down list. Click Add to add new lines.
Dialed Number, prefix: 5, and select 2 digits from the drop down list. Add as many extension ranges as you require for your setup.

Resulting Call, Prefix: Leave the prefix blank, and select Entire Dialed Number from the drop down list
In the More Actions drop down box, select AsteriskServer under Existing Gateways.

Press OK to save and return to the dial plans list. Move the new dial plan to the top of the list, by ticking the box next to the new plan, and pressing Move up repeatedly. Order does matter, so it is at the top. If you don't plan on using the sipX server for any other SIP traffic, you can delete the other dial plans.

Activate the new plans by clicking the Activate button, and pressing OK when prompted for confirmation. Remember that whenever you make any changes to your dial plan, or modify your mapping and auth rule XML files, you must reactivate your dial plan for the change to take effect.

Add an Extension

We will now add an extension for testing purposes. This will help in your troubleshooting efforts should something not work. Click on Users on the top menu, click the Users menu item, and click Add User. Click Show Advanced Settings at the top of the page. Change the user ID to 300, assign a first name, last name, PIN, and SIP password to the account. Take note of the SIP password or change it to something you are going to remember. Press OK when you are done.

Configure the Fully Qualified Domain Name

Click the System menu and the Domain menu item, and enter the fully qualified domain name that the sipX server will use. When prompted, ensure you activate the new dial plans for our configuration changes to take effect.

Please note that the FQDN must be the same as the value you configured as the UM IP Gateway address on the Exchange UM Server.

We have now completed the configuration of the sipX server.

Next: Part 5 - Configuring the SIP Client
Previous: Part 3 - Configuring the Exchange Server

Asterisk/SipX bugs and modifications for UM

noreply@blogger.com (Ryan Newington) — Fri, 05 Oct 2007 23:30:00 +0000

There are a few problems people have been running into with their UM setups.

Intermittent Timouts

The first is a problem where a timeout occurs intermittently when trying to call the Exchange UM server (approx 1 in 4 calls fails). This is caused by a bug in sipX 3.6 sending a malformed SIP header. The good news is that this has been fixed in sipX 3.8, however this version is still in beta (RC2). I have been waiting for a few months for the final release which is apparently 'just around the corner' to update the guide, but it seems to be causing people enough grief to justify posting about this issue now. I have been using 3.8 RC2 myself for some time, and have not run into any problems. The repo can be downloaded from http://sipxecs.sipfoundry.org/temp/sipXecs/sipxecs-unstable-centos.repo. As soon as 3.8 is released, I will update the instructions accordingly.

Play on Phone

The other issue people have been encountering is 'Play on Phone' not working from Outlook or OWA. A SIP trace reveals that Asterisk is sending a 407 Proxy Auth Required to the Exchange server, which it is unable to respond to. In order to get this working, we need to change the SIP connection type settings in each extension definition from friend or user to peer.

If you are using Trixbox (2.2 and above), then using FreePBX, go through each extension in the extension configuration menu, and change the 'type' option to peer as shown below.

If you are not using Trixbox, then you will need to manually modify your extension definitions in sip.conf and ensure the type is specified as 'peer'.

OCS 2007 Downloads now available on Technet/MSDN

noreply@blogger.com (Ryan Newington) — Mon, 20 Aug 2007 11:07:00 +0000

I just checked the Technet website, and Office Communications Server 2007 and Office Communicator 2007 are now available to download. If you haven't signed up for a Technet/MSDN subscription, you can visit http://technet.microsoft.com/en-au/subscriptions/ and sign up now. A full list of the benefits of a Technet Plus subscription can be found on the Technet site, but some of the highlights include:

Microsoft software licensed for evaluation purposes: Evaluate full-version commercial products--without time limits or feature limits, including Windows Vista™ Microsoft Office System and Exchange Server 2007. With full-version software, IT Professionals can make informed decisions about new technologies and deployments at their own pace.

Beta software: Automatically receive pre-release versions of Microsoft operating systems, servers and business applications.

Exclusive tools: Get access to exclusive tools not available to the general public such as System Center Capacity Planner. System Center Capacity Planner helps size and plan deployments of Microsoft Exchange Server and Microsoft Operations Manager. It provides you with the tools and guidance to deploy efficiently, while planning for the future by allowing for "what-if" analyses.

Professional Support incidents: For the toughest technical questions, a TechNet Plus subscription also comes with two complimentary Professional Support incidents**. Subscribers can talk to a Microsoft Support Professional to quickly resolve their mission-critical technical issues fast.

Unlimited Managed Newsgroup support: TechNet Plus provides access to over 100 Managed Newsgroups. Subscribers can exchange ideas with other IT Professionals and get expert answers to their technical questions within the next business day — guaranteed.

Technical resources for Microsoft products: Subscribers also get the TechNet Library containing the Microsoft Knowledge Base, security updates, service packs, resource kits, utilities, technical training, and product documentation to keep their systems and IT skills up to date.

Microsoft E-Learning courses: To prepare them for certification or simply to help them build their technical skills, TechNet Plus includes a selection of Microsoft E-Learning courses for free each quarter.

Online Concierge Chat: Subscribers can chat with a Microsoft Search Assistant online for help finding the technical resources they need or for assistance with non-technical questions.

Free subscription to TechNet Magazine:†† Subscribers also receive a free subscription to TechNet Magazine. TechNet Magazine provides hands-on information to help IT Professionals maximize their system’s security, reliability, scalability and interoperability.

Technet Plus is a very valuable resource for any IT Professional or support group. No MCSE should be without it.

Windows Internals - a "must read"

noreply@blogger.com (Ryan Newington) — Sun, 12 Aug 2007 10:56:00 +0000

If you work with Windows servers and clients, in either a support role or as a developer, then this book is a must read. MCSEs will find it gives a valuable insight into what Windows is doing behind the scenes, and how to best manage it. If you thought you knew all there was to know about Windows, well, your wrong. Written by Mark Russinovich (of WinInternals fame) and David Solomon (noted expert on Windows internals), it delves into the inner most workings of the kernel and its architecture.

It includes in depth information on:

Concepts and Tools
System Architecture
System Mechanisms
Management Mechanisms
Startup and Shutdown
Processes, Threads, and Jobs
Memory Management
Security
I/O System
Storage Management
Cache Manager
File Systems
Networking
Crash Dump Analysis

Go and have a look inside at Amazon.com.

Microsoft Office Roundtable

noreply@blogger.com (Ryan Newington) — Sat, 11 Aug 2007 10:14:00 +0000

This is one of the coolest things I have seen in a while. A 360 degree video conferencing camera.

The Technet Australia team got their hands on one and posted these details about it.

The device creates a 360-degree, panoramic video of side-by-side images of everyone who is taking part in the conference. It tracks the flow of the conversation, so the image and voice of the person who is speaking are spotlighted. People across many locations can attend meetings together virtually.

RoundTable works with Office Communications Server 2007 and Office Live Meeting, allowing companies to integrate virtual presentations, shared whiteboards and file sharing into their audio/video conferences. If someone misses a conference call, the RoundTable sessions can be recorded and viewed later.

The Microsoft Office Roundtable device

The Roundtable device in action using Microsoft Office Live Meeting

Close up of the panoramic view

Awesome! I want one! Definitely going on the shopping list.

Unified Communication continues to amaze me. One can already sense how much UC is going to change the way we communicate. The industry is growing and adapting so rapidly. Vendors and service providers that get their foot in the door today are going to ensure they secure a firm place in this rapidly growing market - its going to boom!

More OCS Info

noreply@blogger.com (Ryan Newington) — Sat, 11 Aug 2007 09:54:00 +0000

Johann has recently posted information about some of the features in the upcoming OCS 2007 release. He also talks about his personal experiences with OCS/OC.

Software powered VoIP: by using a smart end-point (aka a PC), OCS and Communicator 2007 allow a much richer experience than traditional VoIP systems.
Software economics: OCS works with a broad range of devices, phones, applications from a wide range of partners.
Voice quality: The listening and call quality offered by a pre-release version of Office Communications Server 2007 was “considerably better than that provided by [a leading provider’s] IP phones,” according to an independent benchmark study conducted by Psytechnics, a firm specialising in voice-quality research.
Easy transition: Companies can get more value from their existing PBX systems, networks and desk phones by using Office Communications Server to add VoIP and unified communications capabilities without ripping and replacing existing investments.
Streamlined communications: click-to-call from Outlook, Word, Sharepoint and other apps - including the ability to simply add presence and telephony/video to LOB or custom applications/websites.
Tools that travel: It doesn't matter if you're in the office sitting at your desk, working from home, or sitting at a coffee shop - you still have all of your communications tools available. In fact right now I am writing this from a hotel in Seattle. My girlfriend in Sydney can dial my local 02 phone number and I take the call over here on my PC. All of this without a VPN!! As long as I have web access, then I can make and receive calls - and due to our adaptive codecs (more info below) it doesn't matter that I am running across an unreliable unmanaged network (aka the Internet).

The OCS downloads are still not yet available on Technet/MSDN.

OCS and OC 2007 trial versions available now

noreply@blogger.com (Ryan Newington) — Tue, 07 Aug 2007 08:22:00 +0000

Roger Sleurink from Trends IT writes to tell me that the trial versions of Office Communications Server 2007 and Office Communicator 2007 are now available for download. Thanks for the heads up Roger.

OCS 2007: http://www.microsoft.com/downloads/details.aspx?FamilyID=663e5ef7-2288-46b0-9142-b2135a8fbdb9&DisplayLang=en

OC 2007: http://www.microsoft.com/downloads/details.aspx?FamilyId=7F5AB627-2D34-470D-9393-8B3EDE6FE3C4&displaylang=en

I have checked the TechNet site, and it doesn't look like OCS has made it to the subscriber downloads yet. It seems that the subscriptions site has had a much needed face-lift though.

I have been busy migrating my servers to new hardware this weekend, and have a little more work to do, at which point I'll be setting up OCS 2007 to work with Asterisk and sipX.

Doug Behl from the Malibu Software Group and I have spent the past several weeks working on tightening the integration between Asterisk and Exchange. With the two of us being on opposite ends of the planet it has generally meant we were 'following the sun' with at least one of us working on this at any point in the day. He has also had a head start on the OCS integration and has provided me his configuration details to start with. Thanks for all your help so far Doug!

Configure Asterisk to receive incoming SIP calls

noreply@blogger.com (Ryan Newington) — Sat, 28 Jul 2007 02:25:00 +0000

If you want people from the outside world to be able to contact you via SIP, there are a few things you need to configure.

First, in FreePBX setup, click General Settings on the left hand menu, scroll down and select Yes to Allow Anonymous Inbound SIP Calls.

The Asterisk configuration file sip.conf defines the parameters for accepting incoming SIP calls. We need to make some changes to this file to correctly process incoming calls. From the Trixbox Admin web page, click Asterisk, Config Edit, then sip.conf on the left hand side. Modify the contents of this file so it reflects what is shown below.

[general]
bindport=5060 ; UDP Port to bind to
bindaddr=0.0.0.0 ; (0.0.0.0 binds to all)
disallow=all
allow=ulaw
allow=alaw
allow=gsm
allow=ilbc
context=from-sip-external
callerid=Unknown
tos=0x68

;------------- Ryan's Mods --------------
externip=203.214.45.124 ;required behind NAT
localnet=192.168.0.0/255.255.255.0 ;required behind NAT
fromdomain=lithiumblue.com
canreinvite=no ;Required for UM calls to work
insecure=very
srvlookup=yes ;Required for outbound calls

#include sip_nat.conf
#include sip_custom.conf
#include sip_additional.conf

Explanation

bindport - The UDP Port to bind to. Standard is 5060
bindaddr - The IP address to listen on
disallow - Always specified first to disable all codecs, then we use allow to specify only the ones we want to use
context - The section to send SIP calls to for processing. From-sip-external will process calls provided that Allow Anonymous Inbound SIP Calls is set to Yes. Otherwise, it will just give a busy tone.
tos - Type of Service - used for traffic prioritization if supported on the network
externip - If you are behind a NAT, set this value to your public IP address. If you are not behind a NAT, delete this line.
localnet - If you are behind a NAT, set this value to your local subnet and network mask values. Note you can have multiple localnet= lines
fromdomain - Use if you want asterisk will append a domain (rather than its own hostname) to outgoing calls. Note that for people external to your organization to be able to contact you using this domain, the appropriate DNS SRV records must be configured on your public facing DNS servers.
canreinvite - Must be set to 'no' to enable diversions to Exchange UM to be processed correctly. Setting to 'yes' will result in calls being dropped and Event ID 1150 logged on the UM server by UMCore saying "The Unified Messaging server was unable to create a message for the fax call with ID...".
srvlookup - Must be set to 'yes' to allow Asterisk to make outbound SIP calls external to your organization. See Understanding DNS SRV records and SIP for more details.

Some people suggest using nat=yes in sip.conf if your Asterisk server is behind a NAT. I have found that this is not needed, and tends to break calls/diversions to Exchange when enabled. As long as the externip and localnet settings are present, Asterisk should have no problem processing the call from behind a NAT. If you have individual extensions are behind a NAT, you can set nat=yes in each extension definition in sip_additional.conf. This is required in this scenario, and will not break diversions or calls to Exchange.

A detailed guide on all the options available in sip.conf is available on the voip-info.org wiki.

Port Forwarding

If your Asterisk server is behind a NAT, you will need to configure port forwarding on your router. You will need to forward the following ports to the Asterisk server.

Service Name: SIP
Port: 5060
Protocol: UDP

Service Name: RTP
Port: 10000-20000
Protocol: UDP

If you need to change the RTP port range, use the Config Edit web interface to modify the rtp.conf. Read my post on RTP and SIP to understand their relationship and why you need this.

[general]
rtpstart=10000
rtpend=20000

DNS SRV Records

SIP relies heavily on DNS SRV records to be able to route calls through over the internet. To ensure people are able to contact you, configure the following SRV records on your public facing DNS servers.

_sip._udp.mydomain.com. 86400 IN SRV 10 5 5060 asterisk.mydomain.com.

_sip._udp.asterisk.mydomain.com. 86400 IN SRV 10 5 5060 asterisk.mydomain.com.

I have created instructions for configuring these records using Windows Server DNS, as well as a description of how SIP uses SRV records.

And finally....

You may also want to configure SIP aliases so that incoming calls can be directed to an alias@yourdomain.com rather than extnumber@yourdomain.com.

Enabling inbound calls to Exchange UM from the PSTN using Asterisk and an external VoIP service provider

noreply@blogger.com (Ryan Newington) — Sat, 28 Jul 2007 01:29:00 +0000

After confirming that Asterisk can contact the Exchange Server, we can configure our links to the outside world. Asterisk is highly customizable in this regard. You can connect to a VOIP provider, that provides you a PSTN telephone number using a 'soft line', or you can connect physical 'hard lines' to the server using relatively cheap PCI cards. These instructions will involve configuring a soft line to a VOIP provider. In my case, my ISP, iiNet, provides a VOIP line with my ADSL account, but there are companies out there that provide this service for a fee. Please note the exact configuration settings may differ slightly from provider to provider, depending on the gateway they are using. A great place to start is the Whirlpool forums, which contain a lot of information about configuring Asterisk to work with various provider settings.

Create the Trunk

In the FreePBX setup menu, click Trunks, and Add SIP Trunk. Add the following information.

Outbound Caller ID: The PSTN phone number assigned by your provider
Leave Never Override Caller ID unticked
Leave Maximum Channels blank
Leave Dial Rules blank
Leave Outbound dial prefix blank
Trunk Name: PSTNOut
In Peer Details, enter the following information

disallow=all
allow=alaw&ulaw
canreinvite=no
context=ext-did
fromdomain=iinetphone.iinet.net.au *REPLACE WITH THE PROVIDER's DOMAIN*
fromuser=039029XXXX (REPLACE WITH YOUR ASSIGNED USERNAME, USUALLY THE PHONE NUMBER*
host=sip.vic.iinet.net.au *REPLACE WITH YOUR PROVIDERS SIP GATEWAY*
insecure=very
dtmfmode=auto
nat=no
pedantic=no
secret=**YOUR PASSWORD**
type=peer
username=039029XXXX *REPLACE WITH YOUR ASSINGED USERNAME, USUALLY THE PHONE NUMBER*

User Context: PSTNIn
In User Details, enter the following information

canreinvite=no
context=from-pstn
fromuser=039029XXXX (REPLACE WITH YOUR ASSIGNED USERNAME, USUALLY THE PHONE NUMBER*
host=sip.vic.iinet.net.au *REPLACE WITH YOUR PROVIDERS SIP GATEWAY*
insecure=very
dtmfmode=auto
qualify=no
secret=**YOUR PASSWORD**
type=user
username=039029XXXX *REPLACE WITH YOUR ASSINGED USERNAME, USUALLY THE PHONE NUMBER*

Register String: 039029XXXX@iinetphone.iinet.net.au:YOURPASSWORD:039029XXXX@PSTNOut/039029XXXX

Please note that register strings vary from provider to provider, please check with your provider that this information is correct. The register string is used by Asterisk to register with the gateway to receive incoming calls.

Additionally, Maurice van der Werf points out that he had to add dtmfmode=auto in order to get DTMF tones working with one VoIP provider (Xs4all), but dtmfmode=info for another provider (VoIPBuster). Check this setting with your ISP, and modify where appropriate.

Submit the changes, and now we need to modify our routes.

Modify the Route

Now we need to modify the outbound route. There is a preconfigured outbound route called 9_outside in Asterisk which we will use. If the route is not there, simply create a new route with the following information.

Click on Outbound Routes on the left hand menu, and click 9_outside. Change the trunk selection in the Trunk Sequence drop down box to SIP/PSTNOut and press Submit Changes.

The nine/pipe character combination tells Asterisk that this route will be used when someone's presses '9' for an outside line. The period is a wildcard character. This means that any calls starting with the number 9 will be use this route. You can substitute 9 with 1 or 0 if you wish. Keep in mind, we have reserved 2-8 for use by various extension pools. If you used one of these numbers, Asterisk would try to route those internal calls out to the PSTN. You may also choose to not use an 'outside line' access number. In this case, simply enter dial patterns appropriate for the phone numbers you need to dial.

Make a test call from X-Lite to a PSTN phone number. Remember to dial '9' before the phone number to get an outside line.

Configuring the Inbound Route

Asterisk by default can't forward an incoming call to any arbitrary number. It must exist as a registered extension on the system. We want our calls coming in from the PSTN to be routed to the Exchange Server's extension, which Asterisk can't do on its own. However, there is a module we can install to do this for us. We will create Miscellaneous Destinations for both the AutoAttendant and Subscriber Access Number, and configure the inbound calls to be forwarded to one of those destinations.

Click Tools on the top menu of FreePBX, then on the left hand side, click Module Admin. Scroll down to the Inbound Call Control section, and click on Misc Destinations. Select Install as the action, and press the Process button at the bottom of the screen. When the module has installed, click Setup at the top of the FreePBX menu to return to the main configuration screen. Click the Misc Destinations option that has appeared on the left hand menu. Enter the following information for our destination.

Description: ExchangeAutoAttendant
Dial: 299

Click Submit Changes, and add a second destination
Description: ExchangeSubscriberAccess
Dial: 222
Click Submit Changes, and then Inbound Routes on the left hand menu. Enter the following information.

DID Number: 039029XXXX *Replace with your phone number*
Leave Caller ID Number blank
Leave Zaptel channel blank
Leave the Fax Handling, Privacy, and Options sections at their defaults.
Under Set Destination, select Misc Destinations, and choose either ExchangeAutoAttendant or ExchangeSubscriberAccess, depending on where you want the incoming calls to go.

Click Submit, then test the configuration by calling your provided PSTN number. The Exchange Server should answer at the other end.

You may now want to configure Exchange for outbound calls from OVA to the PSTN.

Adding SIP aliases to Trixbox/Asterisk Extensions

noreply@blogger.com (Ryan Newington) — Fri, 27 Jul 2007 23:41:00 +0000

One nice feature of SIP is the ability to have an easy-to-remember URI rather than a long phone number to contact someone with.

By default Trixbox doesn't give you an option to assign an alias, and you are stuck with receiving calls only to your extension numbers. If someone from outside your organization wants to call you, they have to call something like sip:123@mysipdomain.com.

The good news is that we can manually add these aliases into the Asterisk configuration files.

From the Trixbox admin web interface, select Asterisk, then Config Edit. Select extensions_custom.conf, and add the following to the end of the file.

[ext-local-custom]
exten => ryan,1,Goto(400,1)
exten => support,1,Goto(400,1)
exten => mark,1,Goto(401,1)
exten => jason,1,Goto(402,1)

This example will forward any calls to ryan@mysipdomain.com or support@mysipdomain.com to extension 400, calls for mark@mysipdomain.com to extension 401, and calls for jason@mysipdomain.com to extension 402.

Asterix -> Asterisk

noreply@blogger.com (Ryan Newington) — Fri, 27 Jul 2007 23:03:00 +0000

Ok so for the last 3 months, I have been misspelling "Asterisk" as "Asterix". I must have spent too many years reading Asterix comic books as a kid.

So now I have it sorted out:

Asterix - Is the little guy from the french comic

Asterisk - Is the IP-PBX

I've gone through and fixed the spelling in the UM guides. Let me know if you see any occurrences I missed or find any broken links.

Understanding DNS SRV records and SIP

noreply@blogger.com (Ryan Newington) — Fri, 27 Jul 2007 11:47:00 +0000

What are SRV records?

DNS SRV records or service records are a type of DNS entry that specify information on a service available in a domain. They are typically used by clients who want to know the location of a service within a domain. For example, in an Active Directory environment, domain joined windows PCs rely on SRV records to locate domain controllers to authenticate to within their domain.

A SRV record record contains the following information:

Service Name: the well know name of the service
Protocol: specifies if this is a TCP or UDP service
Domain Name: the domain name that this record belongs to
TTL: Time to Live value
Class: DNS class field. This always has the value of "IN"
Priority: when multiple hosts are configured for the same service, the priority determines which host is tried first
Weight: A relative weight for records with the same priority
Port: the TCP or UDP port that the service uses
Target: the name of the host providing the service

Here is an example of a SRV record, that specifies that a SIP/UDP server, with a priority of 10, can be contacted at asterisk.lithnet.local, on port 5060.

_sip._udp.lithnet.local. 86400 IN SRV 10 5 5060 asterisk.lithnet.local.

SIP and the SRV record

SIP clients use SRV lookups to determine where to send an outgoing call. Configuring a DNS SRV records means that you can use your domain name rather than the full host name of the server in the SIP address you give to people. For example, without SRV records, people can only call me on 400@asterisk.lithnet.local. If I configure the SRV record shown in the example above, I can drop the hostname, and people can call me on 400@lithnet.local.

How does a SIP client use SRV records?

If I try to call 400@asterisk.lithnet.local, my SIP client will first perform a DNS SRV lookup. It will query its DNS server for the records:

_sip._udp.asterisk.lithnet.local
and
_sip._tcp.asterisk.lithnet.local

If I have either of them configured in my DNS, my SIP client will forward the call to the host and port number specified in the DNS response. If I do not have them configured, the SIP client will try to contact asterisk.lithnet.local directly (by assuming it is a hostname) on the well known SIP port (5060).

An SRV record can also be used to redirect a SIP client to a different server. If I retire my asterisk.lithnet.local, and replace it with newserver.lithnet.local, I can create a SRV record so that calls directed to @asterisk.lithnet.local are forwarded to the new server.

_sip._udp.asterisk.lithnet.local. 86400 IN SRV 10 5 5060 newserver.lithnet.local.

I might also want to direct calls to a non standard port on my asterisk server. I can do this without having to configure the clients at all.

_sip._udp.asterisk.lithnet.local. 86400 IN SRV 10 5 5070 asterisk.lithnet.local.

Correctly configured, SRV records make managing SIP domains a lot easier.

Sounds great... So how do I do?

From a Windows server with the DNS server installed, open the DNS Management MMC. Right click the domain (or subdomain) you are assigning this service to, and select "Other New Records..."

Scroll down to Service Location (SRV) in the list. Type _sip in the service field, select _udp from the protocol field, assign a priority and weight, enter 5060 as the port number, and the host name of your SIP server.

Click OK and your are done. You can view your new SRV record by clicking on the _udp item under your domain. In the example here, I would now be able to receive calls to @lithnet.local extensions, as well as @asterisk.lithnet.local.

Office Communications Server 2007 is on its way

noreply@blogger.com (Ryan Newington) — Fri, 27 Jul 2007 10:34:00 +0000

The new version of Office Communications Server and Office Communicator has been released to manufacturing!

Stay tuned for guides on integrating OCS 2007 with Exchange UM using sipX/Asterisk.

Understanding sipX dial plan configuration files

noreply@blogger.com (Ryan Newington) — Fri, 27 Jul 2007 10:30:00 +0000

When troubleshooting problems with sipX configuration, it is important to understand how the configuration files are generated.

There are 3 main files that make up the sipX dial plan configuration. There are all located in the /etc/sipxpbx folder.

mappingrules.xml

Mapping rules are used to route calls based on host, usernames, and permissions. In the guide to setting up Exchange UM, we also use mapping rules to transform the SIP URI to add the transport=tcp argument required to make a successful connection to an Exchange UM Server.

authrules.xml

Authrules allow restriction of dial patterns and host by various permissions. For example, you can modify the authrules file so that extensions 300-320 require special permission to call external hosts.

fallbackrules.xml

Fallback mapping rules are processed after mappingrules.xml, and are usually used to provide mapping to external systems (for example, another SIP domain, or a SIP server used to external calls)

These files are all generated automatically by sipX. Don't bother trying to change them, because your changes will be wiped next time the sipX service starts. Each of these xml files has a corresponding .xml.in file. When you activate your dial plan in the sipXconfig web interface, it writes the .xml.in file, and restarts the required components. The .xml.in file is then taken to generate the .xml file. So don't bother trying to change the .xml.in file either!

So how do we customize the dial plan? If you followed my guide to connecting sipX to Exchange UM, you would remember making (or downloading from me) two files - external_mappingrules.xml, and external_authrules.xml. However, in order for sipX to actually process these files, we need to add a few entries into /etc/sipxpbx/sipxconfig.properties.in.

mappingRules.externalRulesFileName=/etc/sipxpbx/external_mappingrules.xml

authRules.externalRulesFileName=/etc/sipxpbx/external_authrules.xml

fallbackRules.externalRulesFileName=/etc/sipxpbx/external_fallbackrules.xml

This tells sipX to integrate our external files into the dial plan when generated. So when configured correctly, our main config file (ie authrules.xml) is generated by combining our .xml.in file, with our external rules file

authrules.xml.in + external_authrules.xml => authrules.xml

If there is problem with the XML code in our external rules files, sipx will ignore them and not process them. You can tell if your files are being processed correctly by viewing the main xml file, and making sure that the external rules have been incorporated into in. If the external rules are missing, go back and check the external rules file, and make sure all tags are spelt correctly, and are have matching closing tags. You can use the following command to verify your XML files:

sipx-validate-xml /etc/sipxpbx/filename.xml

Understanding the relationship between SIP and RTP

noreply@blogger.com (Ryan Newington) — Mon, 23 Jul 2007 10:12:00 +0000

Getting your head around SIP and RTP traffic flows is a little daunting at first, but its actually not all that complicated when you understand the purpose of the protocols.

As its name implies, the Session Initiation Protocol is used to initiate a session between two endpoints. SIP does not carry any voice or video data itself - it merely allows two endpoints to set up connection to transfer that traffic between each other via the Real-time Transport Protocol (RTP).

The SIP protocol can be, and usually is, routed through one or more SIP proxy servers before reaching its destination. It is very similar to how email is transmitted, in that multiple email servers are usually involved in the delivery process, each forwarding the message in its original form. Each email server adds a Received header to the message, to track the route the message has taken. SIP uses a Via header to track the SIP proxies that the message has passed through to get to its destination.

SIP uses a very similar message format to HTTP. They are both human-readable, and use similar (if not the same) error codes. For example, both HTTP and SIP use 408 as the error code to signal a timeout error, 404 for 'not found', etc. Using wireshark, you can capture SIP packets and read the content of them.

Here is a breakdown of the structure of a SIP packet (Click to enlarge).

1. This shows the source and destination IP addresses of the SIP packet. Note this information will change as the packet passes between SIP proxy servers.

2. Transport Protocol and port. In this case, this is a SIP/UDP packet being sent to port 5060 (the standard SIP port)

3. This is the SIP Request header that tells us what type of SIP message this is. This particular packet is a SIP INVITE request for extension 401 @ asterisk.lithnet.local

4. The Via header contains a list of all SIP proxy servers that this packet has passed through, including the initiating client

5. The To header specifies the SIP packet's destination

6. The From header specified who sent the SIP packet

7. This particular packet is a SIP/SD packet, meaning it contains a Session Description Protocol message that contains information the remote client needs to open an RTP session for this call

8. The IP address of the SIP client that created this packet

9. The IP address the destination SIP client should contact to open an RTP session. It also specifies the IP Address version (IPv4 or IPv6)

10. The key pieces of information in this header are audio, 33438, and RTP/AVP. The audio component obviously signifies that this is an audio call, 33438 specifies the port that the remote computer should open at the IP address specified in (9), and RTP/AVP specifies that the Real-time Transport Protocol will be used for the session. The numbers at the end of this header represent the different codecs that this client supports. The SIP client at the other end must support one of the matching protocols in order to be able to make a successful connection.

Unlike SIP, which listens on port 5060 (usually UDP, but can be TCP), RTP uses a dynamic port range (and is only ever UDP), generally between 10000-20000. This range can usually be customized on the client to suit differing firewall configurations.

Now while SIP traffic passes from one server to the next to get to its destination, RTP sessions are set up directly between SIP clients (There is an exception to this rule, that I will explain shortly).

Here is an easy way to think of this. I want to call Bob on the phone, but I don't know Bob's number. I do however have his email address. So I send Bob an email telling him to call me on my phone number. The email passes through several servers and eventually arrives at Bob's inbox. Bob reads the email containing my phone number, picks up the phone, and calls me. We can then begin our audio conversation with each other. The email was used to help us set up a phone conversation, and after that it was no longer needed. Our phone call did not have to pass through the servers my email passed through to get to him, because they are two separate systems. The email in this example is analogous to a SIP packet, the phone call is our RTP session.

Now SIP is a good protocol, but things kind of break down when NAT gets involved. SIP packets themselves tend to move about without too much trouble (generally), as they 'hop' from one server to another. RTP sessions are somewhat more troublesome. Either both clients need to be aware they are behind a NAT, and substitute their local IP addresses for their public IPs in their Session Description messages and open the appropriate firewall ports, or something has to modify the SIP packets en route.

This is where the exception to the rule that I mentioned comes into play. Products known as Back-to-Back User Agents, one of the most well known being Asterisk, can can actually proxy RTP traffic.

Asterisk can modify SIP packets to direct the caller and destination to establish an RTP session with itself, rather than with each other. This is useful in situations where two SIP clients may not have direct access to each other, most commonly, when one or both of the SIP clients are behind a NAT.

It is important to note that Asterisk only proxy's RTP traffic when it has to, and when configured to do so. If both clients are on the same local network segment, Asterisk doesn't need to play a part in the RTP session, and it will proxy only the SIP traffic.

In summary, when troubleshooting packet captures, pay close attention to;

1. The ports and IP addresses specified in the SIP message header (to, from, via). Determine where the packet came from, where it thinks it needs to go, and the route it has taken to get to where you found it.

2. The ports and IP addresses specified in the Session Description (SD) portion of the SIP message. Ensure that the remote party will be able to connect to both the IP address and the port specified.

Unified Messaging in an Office Communications Server 2007 environment

noreply@blogger.com (Ryan Newington) — Sat, 21 Jul 2007 13:45:00 +0000

I've been doing some research on Office Communications Server 2007, and plan on getting this up and running soon. I have been wondering how it will integrate with Exchange UM.

The guys over at the Microsoft Exchange Team Blog have just posted on how OCS 2007 and Exchange UM will integrate to provide voicemail, auto attendant, and subscriber access through OCS.

I will be providing details on my experience integrating the two products with sipX and Asterisk in the future.

If you haven't already subscribed to their blog, do it now. It is one of the most informative blogs at Microsoft, that covers information every Exchange admin needs to know.

Site Updates

noreply@blogger.com (Ryan Newington) — Sat, 21 Jul 2007 13:39:00 +0000

Ok, so I thought it was time for a new site theme. The old theme was good because it stretched to use up all the available space on the screen, but it was uuuuugly.

So this theme is a little prettier, but things seem a little squishy. I don't have the patience to deal with HTML/CSS/whatever it is web sites are rendered in these days to fix it.

Can anyone recommend any good blogspot.com themes?

I also added links to all the Exchange UM setup posts on the right for easy access, as well as my contact details. If you get stuck with anything in your UM/sipx/asterisk setup, feel free to email me.