Saturday, July 28, 2007

Configure Asterisk to receive incoming SIP calls

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.

bindport=5060 ; UDP Port to bind to
bindaddr= ; ( binds to all)

;------------- Ryan's Mods --------------
externip= ;required behind NAT
localnet= ;required behind NAT
canreinvite=no ;Required for UM calls to work
srvlookup=yes ;Required for outbound calls

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


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 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.


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. 86400 IN SRV 10 5 5060 86400 IN SRV 10 5 5060

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 rather than

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

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



User Context
In User Details, enter the following information


Register String:

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

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

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.

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 or to extension 400, calls for to extension 401, and calls for to extension 402.

Asterix -> Asterisk

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.

Friday, July 27, 2007

Understanding DNS SRV records and SIP

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:


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

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

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.


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 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.


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 file. When you activate your dial plan in the sipXconfig web interface, it writes the file, and restarts the required components. The file is then taken to generate the .xml file. So don't bother trying to change the 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/




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 file, with our external rules file + 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

Monday, July 23, 2007

Understanding the relationship between SIP and RTP

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.

Saturday, July 21, 2007

Unified Messaging in an Office Communications Server 2007 environment

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

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 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.

Sunday, July 8, 2007

No iPAQ 510 in Australia

After months and months of waiting for HP to release the perfect Exchange UM companion - the HP iPAQ 510 Voice Messenger, my HP distributor has informed me that HP are not releasing it in Australia! URGH!

Apparently the 600 series is being released over here in August, but I can't find anything about it on the HP site or on the web in general.

Do I wait for the mysterious 600 series, or take my chances with warranty issues and start shopping internationally on eBay?

To Tech.Ed or not to Tech.Ed?

So its that time of the year again. Tech.Ed 2007 in Australia in August. I went for the first time last year and it was great. It was just before the Vista/Office/Exchange 2007 launch, so there were lots of new things to see. I'm trying to decide if I should go this year, or skip a year and go next year. Is there going to be that much new stuff to see after only 12 months? If there anyone has been to Tech.Ed 2007 elsewhere in the world already and has some info, let me know what the content is like.

Is anyone reading this going to Tech.Ed 2007 in Australia? Drop me a line, and let me know the content you are interested in. If I end up going, we might be able to get a group together and meet up one night.

Trixbox/Exchange Voicemail setup

No sooner had I posted Shaun's Asterisk/Exchange setup instructions, James Brooks emailed me with instructions specifically for Trixbox. I have included his email below. Thanks very much for taking the time to work this out and send it in James.



First of all can I just thank you for adding to the efforts of Alginald in interfacing Asterisk to Exchange 2007 UM; your instructions are concise and accurate, and I for one could not have got this far without them.

Secondly my best wishes for a speedy recovery of your Dad.

Following on from Shaun's Asterisk instructions, in order to get Trixbox diverting voicemail calls to Exchange 2007 you need to do the following:

1. Make sure that Trixbox Voicemail module is installed

2. Enable Voicemail for each extension you want to have voicemail in FreePBX within Trixbox, assign a PIN/password although it won't be used

3. Modify your extensions.conf file within /etc/asterisk (I used the Trixbox - Admin > Asterisk > Config Edit option) as follows:

a. Locate the [macro-exten-vm] section

b. Comment out the line:

exten => s,n,Macro(vm,${VMBOX},${DIALSTATUS})

so that it reads:

;exten => s,n,Macro(vm,${VMBOX},${DIALSTATUS})

c. Beneath the newly commented-out line, add the following two lines, replacing 222 and sipx.lithnet.local with the Exchange Subscriber Access number and your sipX FQDN respectively:

exten => s,n,SIPAddHeader(Diversion: <tel:${EXTTOCALL}>\;reason=no-answer\;screen=no\;privacy=off)

exten => s,n,Dial(

4. Save/update the modified extensions.conf file and restart the Asterisk services or reload config.

Hope the above is of help...

Warm regards,


Thursday, July 5, 2007

Asterisk/Exchange Voicemail

Shaun Ewing kindly sent me the details of how he got Asterisk working with Exchange UM Voicemail. I will test and integrate this into the instructions shortly. Thanks very much Shaun!


Hi Ryan,

Just wanted to send you through an email thanking you for the instructions for getting Asterisk to talk to Exchange 2007. We don’t actually use Asterisk as our phone system, but I wanted to demo the functionality of Exchange UM for our upcoming Cisco Callmanager rollout.

Thought I’d let you know that using Exchange 2007 for Asterisk voicemail is surprisingly simple.

Let’s say you have the following in extensions.conf (for Asterisk VM):

exten => _93XX,1,Dial(SIP/uri17r)

exten => _93XX,2,Voicemail(su${EXTEN})

All you need to do is adjust it to do the following:

exten => _93XX,1,Dial(SIP/uri17r)

exten => _93XX,2,SIPAddHeader(Diversion: <tel:${EXTEN}\ ;reason=no-answer\;screen=no\;privacy=off)

exten => _93XX,3,Dial(SIP/pilot@exchange60)