Postgresql 9.1 Streaming replication on ubuntu 12.04 part 1

Setting up PostgreSQL Replication

I have a need to set up a PostgreSQL Replication Database.   In Postgres 9.0+  they have the ability to have a read only replicated database that mirrors the live database, it can lag slightly behind the live database (although in my simple test it was spot on).  The Replication DB can be read from but not written to.  In my particular case I just want to use it as a failover DB that can be brought up as a live DB if ever needed.

Here is set up.  I have two Ubuntu 12.04 LTS 64 bit servers with postgresl 9.1 installed.  One of these servers will be the primary (master) PostgreSQL server and the other will be the replication (slave) postgres server.  

Set up a test Database :

To do a full test I am going to log into my PRIMARY server and create a new database.  The purpose of the database is for testing. Useful in the last phase.

Log into the DB

> sudo su postgres         >   psql -d postgres -U postgres

Create a test user

>    CREATE USER navneet WITH PASSWORD ‘rathi’;

Create the Database

>    CREATE DATBASE nanddb;

Make sure it was created by running \l  

Grant navneet privileges to this database

>    GRANT ALL PRIVILEGES ON DATABASE nand to navneet;

Now let’s test it quit out of postgres and try

>    \q         >    psql -d nand -U navneet

And I get an error 

 The authentication is peer not (md5/trust)

I am trying to log in as navneet but I am logged in as the postgres user. It’s a setting in “/etc/postgresql/9.1/main/pg_hba.conf “. I failed to edit

Edit the file

>    sudo vi   /etc/postgresql/9.1/main/pg_hba.conf

Change

# "local" is for Unix domain socket connections only local   all             all                                     peer

To

# "local" is for Unix domain socket connections only local   all             all                                     trust

It will allow all local user to login without password .if you try to login from outside it will ask for password if you create a ssh tunnel no password is needed.

And restart PostgreSQL to take the effect of new settings.

>    sudo /etc/init.d/postgresql  restart  or  >  service postgresql restart

And then log back in

>    psql  -U navneet nand

This time it worked!

Now connect to the database.

>    \c nand

Create a simple table that I can send updates to.  The purpose of this table is to test the set-up of the replication server.  The live server should be able to continue getting updates while the replication server is being set up, then it will “catch up”

>    CREATE TABLE data(         >      id serial primary key not null,         >      time timestamp not null default CURRENT_TIMESTAMP,         >      number integer not null         >  );

This creates a table with a primary key that auto increments, and a time field which will default to the current_timestamp

Run the following command to confirm the table has been created and is working as intended.

>    \dt         >    select * from data;         >    INSERT INTO data (number)         >    VALUES (34);         >    select * from data;

OK now that I have set up I need to create a simple program to insert data into this table on some kind of loop.

Writing a simple python program

First I had to install some libraries that python depends on for talking to PostgreSQL

>    sudo apt-get install python-psycopg2         >    vi insertDB.py

Here is my python code

#!/usr/bin/python # # #  Simple Script to insert data # import psycopg2 import sys import time con = None try:     # First get the current maximum     con = psycopg2.connect(database='nand', user='navneet', password='rathi')     cur = con.cursor()     cur.execute('select MAX(number) from data')     x = cur.fetchone()[0]     if x is None:        x = 0     while (True):         x = x + 1         cur.execute('INSERT INTO data(number) VALUES (' + str(x) + ')')         con.commit()         print 'inserting ' + str(x)         time.sleep(1) except psycopg2.DatabaseError, e:     print 'Error %s' % e     sys.exit(1) finally:     if con:         con.close()

It will connect, locally to my PostgreSQL database and query the data table to find the largest integer in the number field. The program then increments it by one and inserts the new values (always pausing 1 second and incrementing by 1).

The idea is this is constantly adding data to the database, so that I can confirm that the replication I create works correctly.

WAL (write ahead log) Files

Postgres uses write ahead logging

“WAL's central concept is that changes to data files (where tables and indexes reside) must be written only after those changes have been logged, that is, after log records describing the changes have been flushed to permanent storage.”

First let’s go find the WAL files. /etc/postgresql/9.1/main/postgresql.conf file under the data_directory field.  In 9.1 its typically /var/lib/postgresql/9.1/main At any rate the WAL files are located in the pg_xlog folder within the DB folder

>    cd  /var/lib/postgresql/9.1/main/pg_xlog         >    ls -alh

Here you should see several files that are 16MiB in size with numbers for names.

These are the WAL files.   In the /etc/postgresql/9.1/main/postgresql.conf file there is a wal_keep_segments field which is typically set to 0.  If it is set to 0 it means that at least 0 WAL files must be kept in the queue.  More typically are here as the DB needed.   This setting must be increased to assure that the replication database has access to them.

Primary (Master) DB settings

First let’s set up the master DB to be able to allow replications DBs to get the updates they need

postgresql.conf

First we need to edit /etc/postgresql/9.1/main/postgresql.conf

>    sudo vi  /etc/postgresql/9.1/main/postgresql.conf

The following needs to be edited (the approx @line is to show where the typical line number is for this setting)

@line 61 listen_addresses = '*'          # what IP address(es) to listen on; @line 155 wal_level = hot_standby                  # minimal, archive, or hot_standby @line 198 max_wal_senders = 5                # max number of walsender processes @line 201 wal_keep_segments = 128         # in logfile segments, 16MB each;

Here is the “why” for each as best as I have researched.

listen_addresses = '*'       

Listen to any incoming connection. 

wal_level = hot_standby

This must be set to archive or hot_standy .  The default minimal does not put enough information in the WAL files to truly reconstruct the Database.

max_wal_senders = 5              

Sets number of concurrent streaming backup connections.   I think you could get by with 1 if you only have 1 failover server; I just set to 5 because all the other were doing it. 

wal_keep_segments = 128

This will keep at a minimum 128 WAL files.  At the default size of 16MiB that totals 2 GiB.  This is a lot but I want to make sure I do not lose anything on the transfer.

pga_hba.conf

Now edit /etc/postgresql/9.1/main/pga_hba.conf

>    sudo vi  /etc/postgresql/9.1/main/pg_hba.conf

Add this line to the bottom

host     replication    postgres        172.16.2.208/32        trust

This just says to trust the server at 172.16.2.208, which is my replication server.

Replication Role (First check & do it if Required)

I made a mistake when I first did this I did not realize there is a replication role in the database that must be designated.

When I simply tried to use the postgres user I got the following error.

2012-04-21 08:26:01 MDT FATAL:  could not connect to the primary server: FATAL:  must be replication role to start walsender

I am using the postgres user as the replication user.   To see what the postgres user has run the following command from the postgres database.

>    \du

Here you can see that my postgres user does not have the “Replication” Role.

So I added the role to my postgres user, most sites I found suggest creating a new user that only handles replication.   I decided to just go with reusing the postgres user.

From the postgres database run this command

>    ALTER ROLE postgres WITH REPLICATION;

Now run the \du command again

>    \du postgres

And you should see this

Now it has the Replication role!

Restart the Primary database

From the command line

>    sudo /etc/init.d/postgresql restart or service postgresql restart

After it has been restarted I kick off my python script. 

>    sudo /etc/init.d/postgresql restart

I left it running in its own terminal

Then I logged into the Database and did a few quick checks to make sure that data is being constantly loaded into the database.

>    psql -d nand –U navneet

Then from psql

>    select count(*) from data;

I ran this a few times to confirm its growing in size.

Copy the Database over to the Replication (Slave) server

My first go at this I screwed it up! .  I thought I could do a simple pg_dumpall from the primary server to the replication server.  I logged into the Replication server and ran these commands.

> sudo su postgres          > time pg_dumpall -h 172.16.2.207 -U postgres | psql -d postgres -U postgres

(I added the time command to see how long it runs)

And then after setting up the replication server and restarting it (which I will get into later) the postgres would not start up and I got this error.

FATAL:  hot standby is not possible because wal_level was not set to "hot_standby" on the master server

But I did set it!  So what is going on?

So here is the correct way of doing it.

First shut off postgres on the replication server

>    sudo su /etc/init.d/postgresql stop

Next log into the primary server and run the following commands

>    sudo su postgres         >    psql -d postgres -U postgres

You are logged into the database

Now tell the database you are going to start a backup.  You can still keep using your database as you normally would, there will be no interruption to incoming data.

>  SELECT pg_start_backup('mybackup_label', true);

From the command line copy your data directory folder from the primary server to the replication server.  In my case the data directory is “/var/lib/postgresql/9.1/main/” (this is set in the postgresql.conf file).  I kept the data directory the same on both primary and replication server.

Here is my command adjust it according to where you data directory is located.

>  time scp -r  /var/lib/postgresql/9.1/main/*   root@172.16.2.208:/var/lib/postgresql/9.1/main/

After the database has been copied over run the following command from the psql, this will say the backup is done on the master server.

>  SELECT pg_stop_backup();

I got this error.  “NOTICE:  WAL archiving is not enabled; you must ensure that all required WAL segments are copied through other means to complete the backup”

I did not set up WAL archiving but I did set up wal_keep_segments, I think this is only a problem if you do not have enough wal segments.   I think I am OK.  Let’s see…

Replication (Slave) DB server settings

Now that we have backed up the database to the slave/replication database, we need to change it to an actual replication database.

postgresql.conf

First we need to edit /etc/postgresql/9.1/main/postgresql.conf

>    sudo vi  /etc/postgresql/9.1/main/postgresql.conf

The following needs to be edited (the @line is to show where the typical line number is for this setting)

@line 59 listen_addresses = '*'          # what IP address(es) to listen on; @line 210 hot_standby = on                        # "on" allows queries during recovery

Here is the “why” for each as best as I have researched.

listen_addresses = '*'       

Listen to any incoming connection. 

hot_standy = on

Allows you to query, but not update the replication DB

recovery.conf

Now the recovery.conf file must be created.   I am using Ubuntu 12.04 with a postgres 9.1 .The recovery.conf file needs to be in the data directory, as defined in postgresql.conf.  In my case that is “/var/lib/postgresql/9.1/main/”

So I copied the /usr/share/postgresql/9.1/recovery.conf.sample file to /var/lib/postgresql/9.1/main/recovery.conf and open it for editing.

>    cd  /usr/share/postgresql/9.1/         >    cp recovery.conf.sample  /var/lib/postgresql/9.1/main/recovery.         >    sudo vi /database/postgresqldata/recovery.conf

The following needs to be edited (the @line is to show where the typical line number is for this setting)

@line 108 standby_mode = on @line 110 primary_conninfo ='host=172.16.2.209 port=5432 user=postgres' @line 124 trigger_file = '/home/nrathi/failover'

Here is an explanation of each of these

standby_mode = on

Just sets the standby mode to on

primary_conninfo

All the information for the replication(slave) server to connect to the primary (master) server.

trigger_file

if this file exists the server will stop being a replication server and start being a primary server.  It checks periodically for this file.

Fix ownership of files. (be very careful the chown command fire it as it is  )

>  sudo chown -R postgres:postgres /var/lib/postgresql/9.1/main/         >  sudo chmod 700 /var/lib/postgresql/9.1/main/recovery.

Now start the postgres database on the replication (slave) server

>    sudo /etc/init.d/postgresql start

Now log into the database

>    sudo su postgres         >    psql -d postgres –U postgres

Then from postgres I ran the following commands

>    \c nand         >    select count(*) from data;         >    select pg_last_xlog_receive_location();

And I can see that it is getting live data!  So that is it you now have a replication server.  

Setup the Quota for internet User.

Using a Simple iptables command we can set up a quota for the internet user

Step 1
Take a Linux machine which will act as a gateway for you and route all the traffic from

All we want to have is the following: packets arriving from the local net with a receipient's IP address somewhere in the internet have to be modified such that the sender's address is equal to the router's address. For further command examples let us assume that the first interface 'eth0' is connected to the local net and that the router is connected to the internet via the second interface 'eth1'. The command for a shared internet connection then simply is:

# Connect a LAN to the internet gt; 
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

#Lets say we have a user for which i have to set a bandwidth of  13 GB/month 
iptables -A INPUT -p tcp -s 192.168.0.2 -m quota --quota 13958643712 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 80 -j DROP
or
iptables -A INPUT -p tcp -j CLASSIFY --set-class 1:12

So in the above rule will allow the user (192.168.0.2)  to user the internet service up to 13 GB

after a month you need to fire
iptables -F
 and run the above command again or even you can schedule a cron job for this .and we are all set the Shell script will look like this.


#!/bin/bash
 # step 1
iptables -F

# Step 2
# Connect a LAN to the internet gt; 
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

 #Step 3
#Lets say we have a user for which i have to set a bandwidth of  13 GB/month 
iptables -A INPUT -p tcp -s 192.168.0.2 -m quota --quota 13958643712 -j ACCEPT

 #Step 4
iptables -A OUTPUT -p tcp --dport 80 -j DROP
or
iptables -A INPUT -p tcp -j CLASSIFY --set-class 1:12
#
#choose one from step 4 as per your requirement
#
#Create a shell script name quota.sh

chmod 777 quota.sh

crontab -e

*        *        1        *        *       /bin/bash  /path to/quota.sh

then save the cron by following keys 'esc' then ': wq'

and we are ready to go.

Compailing a linux on debian system

There are many ways to do it in Debian you can compile from source or directly upgrade the operating system it will upgrade the kernel version automatically  but its the kernel binaries which are available with the archives . I will tell you to compile the kernel from the source and how to apply patch to the kernel.

Each distribution has some specific tools to build a custom kernel from the sources. This article is about compiling a kernel on a Debian Etch system. It describes how to build a custom kernel using the latest unmodified kernel sources from www.kernel.org  (vanilla kernel) so that you are independent from the kernels supplied by your distribution. It also shows how to patch the kernel sources if you need features that are not in there.

1 Preliminary Note

I will describe two ways of compiling a new kernel. Using the first method, you will end up with a kernel .deb package that can be installed on the system, and that you can share with others and install on other Debian Etch systems.

The second method is to compile a kernel the "traditional" way. This way works on any Linux distribution, but of course you don't end up with a kernel .deb package.

2 Building A Kernel .deb Package

This chapter shows how to build a kernel and end up with a .deb package that you can install and share with others.

2.1 Install Required Packages For Kernel Compilation

First we update our package database:

sudo apt-get update

Then we install all needed packages like this:

sudo apt-get install kernel-package libncurses5-dev fakeroot wget bzip2 build-essential

2.2 Download The Kernel Sources

Next we download our desired kernel to /usr/src. Go to www.kernel.org and select the kernel you want to install, e.g. linux-3.8.tar.bz2 (you can find all 2.6 kernels here: https://www.kernel.org/pub/linux/kernel/v3.x/). Then you can download it to /usr/src like this:

cd /usr/src
wget https://www.kernel.org/pub/linux/kernel/v3.x/linux-3.8.tar.bz2

Then we unpack the kernel sources and create a symlink linux to the kernel sources directory:

tar xjf linux-3.8.tar.bz2
ln -s linux-3.8.tar.bz2 linux
cd /usr/src/linux

2.3 Apply Patches To The Kernel Sources (Optional)

Sometimes you need drivers for hardware that isn't supported by the new kernel by default, or you need support for virtualization techniques or some other bleeding-edge technology that hasn't made it to the kernel yet. In all these cases you have to patch the kernel sources (provided there is a patch available...).

Now let's assume you have downloaded the needed patch (I call it patch.bz2 in this example) to /usr/src. This is how you apply it to your kernel sources (you must still be in the /usr/src/linux directory):

bzip2 -dc /usr/src/patch.bz2 | patch -p1 --dry-run
bzip2 -dc /usr/src/patch.bz2 | patch -p1

The first command is just a test, it does nothing to your sources. If it doesn't show errors, you can run the second command which actually applies the patch. Don't do it if the first command shows errors!

2.4 Configure The Kernel

It's a good idea to use the configuration of your current working kernel as a basis for your new kernel. Therefore we copy the existing configuration to /usr/src/linux:

make clean && make mrproper
cp /boot/config-`uname -r` ./.config

Then we run

make menuconfig

which brings up the kernel configuration menu. Go to Load an Alternate Configuration File and choose .config (which contains the configuration of your current working kernel) as the configuration file:

2.5 Build The Kernel

To build the kernel, execute these two commands:

make-kpkg clean
fakeroot make-kpkg --initrd --append-to-version=-custom kernel_image kernel_headers

After --append-to-version= you can write any string that helps you identify the kernel, but it must begin with a minus (-) and must not contain whitespace.

Now be patient, the kernel compilation can take some hours, depending on your kernel configuration and your processor speed.

2.6 Install The New Kernel

After the successful kernel build, you can find two .deb packages in the /usr/src directory.

cd /usr/src
ls -l

On my test system they were called linux-image-3.8.2.5-custom_3.8.2.5-custom-10.00.Custom_i386.deb (which contains the actual kernel) and linux-headers-3.8.2.5-custom_3.8.2.5-custom-10.00.Custom_i386.deb (which contains files needed if you want to compile additional kernel modules later on). I install them like this:

dpkg -i linux-image-3.8.2.5-custom_3.8.2.5-custom-10.00.Custom_i386.deb
dpkg -i linux-headers-3.8.2.5-custom_3.8.2.5-custom-10.00.Custom_i386.deb

(You can now even transfer the two .deb files to other Debian Etch systems and install them there exactly the same way, which means you don't have to compile the kernel there again.)
That's it. The GRUB bootloader configuration file /boot/grub/menu.lst has been modified automatically, and a ramdisk for the new kernel has been create in /boot.
Now reboot the system:

shutdown -r now

At the boot prompt, select your new kernel

If everything goes well, it should come up with the new kernel. You can check if it's really using your new kernel by running

uname -r

Connecting Two Astreisk Boxes Using SIP Trunk Peering

You can peer two asterisk boxes together using SIP or IAX2.This means that we can call from extension connected the asterisk 1 to extension connected to asterisk two.Diagrammatically this can be like as follow.

           
I think now the picture is more clear to you.that what am going to tell you.

Session Initiation Protocol (SIP)) is a signalling protocol used for setting up and tearing down Voice over Internet Protocol (VOIP) calls. Voice over Internet Protocol makes the transition from traditional conference calls to conference calling via the world wide web. A SIP call uses two protocols: SIP and RTP. Real Time Protocol (RTP) is used for the transfer of the actual voice data. If you want to find out more about SIP visit Wikipedia's SIP page.

The first step in setting up an SIP trunk is to draw a picture of what you need to do. Here's an example of a simple PBX to PBX connection that will be using a User/Peer pairing to form a SIP trunk. The two PBXs are name 106 and 111 after their IP host address. They could very well be named Montreal and New York. PBX 106 has all their extensions starting with 3xxx while PBX 111 has all of their extensions starting with 2xxx. This will be handy when making outbound routes.


The SIP trunks are drawn as arrows pointing to their PBX peer and named based on their destination which seems like a good practise. 111-Peer is going from PBX 106 to PBX 111 and 106-Peer is going from PBX 111 to PBX 106. I've left an area on both sides for configuration information.

Note: It is good practise to indicate the protocol used in the naming of trunks, users and peers (ex. 106-SIPpeer). This is very important if you are using multiple protocols for trunking (IAX, SIP and T1). Adding the protocol to the trunk names will create a unique entry and prevent unintentional confusion in the dialplans between trunking protocols!

On the PBX 106 side, I will need to configure an outbound trunk called 111-peer which will connect to the opposite PBX using the account 106-user. PBX 111 will need to create a user account called 106-user on the inbound trunk. It makes sense to call the user account 106-user because that's who is going to register to PBX 111.
Additionally, on PBX 106, we will need an user account called 111-user so that PBX 111's outbound trunk 106-peer can register to. On PBX 111's outbound trunk 106-peer, we tell it to use user 111-user.
The trunk names and usernames can be called anything you like. I tried to use names that would help explain what is happening.
I've made up a SIP trunk using Peer/User pairing configuration tool in an Excel spreadsheet that creates both PBX 106 and PBX 111's trunk configuration. It is easy and fast to do and takes all the guess work out of it. You enter in the IP address (or domain name) of each PBX, the names for the two trunks, the names for the two users and the user passwords. It spits out the configurations for both PBXs in the same format that you see in the FreePBX Add Trunk menu.
The following pages go through the steps to configure the PBXs using the FreePBX interface. We will configure the trunks one side at a time starting with PBX 106. Once both PBXs have their SIP trunks up, we will configure the outbound routes.

1. Configuring the SIP Trunks
   1. Configuring PBX 106 SIP Trunk
   2. Configuring PBX 111 SIP Trunk
   3. Testing the SIP trunks
2. Configuring the Outbound Routes We will be configuring the outbound route for dialing directly to the extension of the peer PBX.
   
   
   • Creating PBX 106's Outbound Route
   • Creating PBX 111's Outbound Route
3. Now you should be able to dial through each PBX to its peer from any SIP, IAX2 or POTS extension. You can check the status of the phones online and trunks online through FreePBX Statistics window
   In creating the trunks, there was no limit put on the maximum number of channels that can use the trunk. For the above FreePBX Statistics window, I had 4 phones (channels) connected in 2 connections (external calls) across the SIP trunk. There are two IP trunks shown here as one is an IAX2 trunk and the other the newly created SIP trunk.
   Two channels were IP phones, one was an IAX2 S100i POTS to IAX2 adapter and one FXS pots phone. All worked beautifully! You don't have to configure any protocol translations - the PBX does it all for you.
   
   
   

   Configuring PBX 106 SIP trunk

   We are going to create a SIP trunk called 111-peer that will connect to PBX 111. At PBX 111 we will be connecting to PBX 111's sip trunk called 106-peer. Confusing? Yes sir!
   
4. Select Add Trunk from the FreePBX main setup menu
5. Select Add SIP Trunk
   
6. Nothing to do here, so go to the Outgoing Settings section
   
7. Above are the default values which we will change to
   
8. Here's the explanation of the changes:
   • Trunk Name: 111-peer - you can name this anything you like, we're going to PBX 111 so 111-peer sounds like a good name
   • host=192.168.1.111 - IP address or domain name of the peer PBX you want to connect to
   • username=106-user - this is the name of PBX 111's user account to authenticate to.
   • fromuser=106-user - this is used during authentication during the SIP invite
   • secret=106-password - this is the password that is used to authenticate the 111-peer SIP trunk to PBX 111.
   • type=peer - this indicates that this trunk is the peer.
   • qualify=yes - this line is optional. It periodically pings its peer to keep the connection alive.
9. Here's the default settings for the Incoming Settings.
   
10. Configure the user account for PBX 111 in this section:
    
    • 111-user - This creates the account that PBX 111 will use on PBX 106
    • secret=111-password - This is the password for 111-user account
    • type=user - This is a user account in the user/peer pairing
    • context=from-trunk - This account is accessed by a trunk
11. Press submit, update and reload.
12. Now go to Configuring PBX 111 SIP trunk

Configuring PBX 111 SIP trunk

We are going to create a SIP trunk called 106-peer that will connect to PBX 106. At PBX 106 we will be connecting to PBX 106's sip trunk called 111-peer.

1. Select Add Trunk from the FreePBX main setup menu
   
2. Select Add SIP Trunk
   
3. Nothing to do here, so go to the Outgoing Settings section
   
4. These the default values which we will change to
   
5. Here's the explanation of the changes:
   • Trunk Name: 106-peer - you can name this anything you like, we're going to PBX 106 so 106-peer sounds like a good name
   • host=192.168.1.106 - IP address or domain name of the peer PBX you want to connect to
   • username=111-user - this is the name of the SIP trunk coming from PBX 106
   • fromuser=111-user - this is required by the SIP invite authentication process
   • secret=111-password - this is the password that is used to authenticate the 111-user account
   • type=peer - sets the trunk as a peer in the user/peer pairing
   • qualify=yes - this line is optional. Periodically pings to keep the connection alive.
6. Here's the default settings for the Incoming Settings.
   
7. Configure the user account in this section:
   
   • 106-user - This creates the account that PBX 106 will use on PBX 111
   • secret=106-password - This is the password for 106-user account
   • type=user - This is a user account in the user/peer pairing
   • context=from-trunk - This account is accessed by a trunk
8. Press submit, update and reload.

Testing a SIP trunk

1. Testing PBX 106 At this point, we are ready to verify that the SIP trunk is alive. The "qualify=yes" line sends an option packet every 60 seconds to see if the destination is alive. If the destination does not respond within 2 seconds for 7 tries in a row, it will be marked as unreachable.
   At the asterisk CLI for PBX 106, I've typed the command 'sip show peers":
   
   
   
   • 111-peer/106-peer means:
     
     • 111-peer - this is the trunk name
     • 106-peer - this is the username
   • 192.168.1.111 - This is the address of the PBX that we are trunking to
   • Dyn - Is it dynamic port addressing or not. I believe that dynamic is for SIP phone extensions and blank is for SIP trunks. I've also read that is could be for dynamic IP addressing. I'll verify this in the lab.
   • Nat - N - We haven't enabled Network Address Translation (NAT) for this trunk
   • ACL -Not sure what this means at this time
   • Port - This is the port that SIP is operating on. It should be 5060 for a SIP trunk. The other ports are dynamically assigned for SIP extensions.
   • Status - If you have the line "qualify=yes", the status will be "OK" with a time in brackets. If you don't add the line, then it will be indicated as "unmonitored" which makes me uncomfortable. Regardless the trunk will still work
   The result is that we are connecting on trunk 111-peer using user 106-peer to the PBX at 192.168.1.111 using port 5060, not NAT and things are OK with a 1 mS ping time. Even if it displays "OK", you may still have SIP authentication issues and the dreaded "All circuits are busy now. Please try your call later." If you are receiving this error message, consult the Troubleshooting SIP webpages.
   
2. Testing PBX 111
   At the asterisk CLI for PBX 111, I've typed the same command 'sip show peers":
   
   
   
   This verifies that we are connecting on trunk 106-peer using user 111-peer to the PBX at 192.168.1.106 using port 5060, not NAT and things are OK with a 1 mS ping time. Even if it displays "OK", you may still have SIP authentication issues and the dreaded "All circuits are busy now. Please try your call later.". If you are receiving this error message,
   
   

   Configuring PBX 106's Outbound SIP Trunk

   This example will configure an Outbound Route so that PBX 106 extensions can dial PBX 111 extensions directly. You start by selecting Outbound Routes
   
   
3. Direct Dial PBX 111's Extensions This outbound rule allows PBX 106 extensions (3xxx) to directly dial PBX 111's extensions (2xxx). For example, to dial PBX 111's extension 2001. You dial 2001.
   
   Three things to configure:
   
   
   • Route Name: 111-dial-2xxx - Can be anything, be descriptive so you remember what it is 6 months from now when it stops working!
   • Dial Patterns: 2xxx - This says any 4 digit extension starting with 2 will be forwarded to the designated trunk.
   • Trunk Sequence: SIP/111-peer - This is the trunk that we configured that goes to PBX 111 

Configuring PBX 111's Outbound SIP Trunk

This example will configure an Outbound Route so that PBX 111 extensions can dial PBX 106 extensions directly. You start by selecting Outbound Routes

• Direct Dial PBX 106's Extensions This outbound rule allows PBX 111 extensions (2xxx) to directly dial PBX 106's extensions (3xxx). For example, to dial PBX 106's extension 3001. You dial 3001.
  
  Three things to configure:
  
  
  • Route Name: 106-dial-3xxx - Can be anything, be descriptive so you remember what it is 6 months from now when it stops working!
  • Dial Patterns: 3xxx - This says any 4 digit extension starting with 3 will be forwarded to the designated trunk.
  • Trunk Sequence: SIP/106-peer - This is the trunk that we configured that goes to PBX 106

 Then configure the one sip phone on one PBX and other on the other PBX and and you are ready to go.