SAIL Community Supported PBX

Happy new year S

I am setting up a new V6.0-51 PBX with a new SIP channel and a legacy DAHDI inbound. The system is very simple (I think), and it is a vanilla install on top of Debian 9.

Having set up the dahdi trunk and a few bits and pieces, the most unusual thing is happening. Anything where SAIL is supposed to take over and route to some internal resource (call group, IVR) is failing with a "sent to invalid extension" error.

So here is an internal call to our 'reception' call group 500, which works until it is supposed to resolve by going to our IVR 510:


    -- Executing [500@internal:1] AGI("SIP/104-00000000", "sarkhpe,OutCos,500,,") in new stack
    -- Launched AGI Script /usr/share/asterisk/agi-bin/sarkhpe
    -- <SIP/104-00000000>AGI Script sarkhpe completed, returning 0
    -- Executing [500@104closedcos:1] AGI("SIP/104-00000000", "sarkhpe,OutCluster,500,,") in new stack
    -- Launched AGI Script /usr/share/asterisk/agi-bin/sarkhpe
    -- <SIP/104-00000000>AGI Script sarkhpe completed, returning 0
    -- Executing [500@qrxvtmny:1] AGI("SIP/104-00000000", "sarkhpe,Alias,SIP/101&SIP/102&SIP/103,500,") in new stack
    -- Launched AGI Script /usr/share/asterisk/agi-bin/sarkhpe
    -- AGI Script Executing Application: (Dial) Options: (SIP/101&SIP/102&SIP/103,20,ciIkt)
  == Using SIP RTP CoS mark 5
  == Using SIP RTP CoS mark 5
  == Using SIP RTP CoS mark 5
    -- Called SIP/101
    -- Called SIP/102
    -- Called SIP/103
    -- Connected line update to SIP/104-00000000 prevented.
    -- Connected line update to SIP/104-00000000 prevented.
    -- Connected line update to SIP/104-00000000 prevented.
    -- SIP/101-00000001 is ringing
    -- SIP/102-00000002 is ringing
    -- SIP/103-00000003 is ringing
    -- Nobody picked up in 20000 ms
    -- <SIP/104-00000000>AGI Script sarkhpe completed, returning 0
    -- Channel 'SIP/104-00000000' sent to invalid extension: context,exten,priority=extensions,510,1
    -- Executing [i@extensions:1] PlayTones("SIP/104-00000000", "congestion") in new stack
    -- Auto fallthrough, channel 'SIP/104-00000000' status is 'NOANSWER'


And here is the inbound DAHDI, noting that I have set '500' as the 'Operator' extension so at least that part works.


-- Starting simple switch on 'DAHDI/1-1'
    -- Executing [s@from-pstn:1] Set("DAHDI/1-1", "chan=1-1") in new stack
    -- Executing [s@from-pstn:2] Set("DAHDI/1-1", "chan=1") in new stack
    -- Executing [s@from-pstn:3] Goto("DAHDI/1-1", "mainmenu,DAHDI1,1") in new stack
    -- Goto (mainmenu,DAHDI1,1)
    -- Channel 'DAHDI/1-1' sent to invalid extension: context,exten,priority=mainmenu,DAHDI1,1
    -- Executing [i@mainmenu:1] Goto("DAHDI/1-1", "extensions,500,1") in new stack
    -- Goto (extensions,500,1)
    -- Executing [500@extensions:1] AGI("DAHDI/1-1", "sarkhpe,Alias,SIP/101&SIP/102&SIP/103,500,") in new stack
    -- Launched AGI Script /usr/share/asterisk/agi-bin/sarkhpe
    -- AGI Script Executing Application: (Dial) Options: (SIP/101&SIP/102&SIP/103,20,ciIkt)
  == Using SIP RTP CoS mark 5
  == Using SIP RTP CoS mark 5
  == Using SIP RTP CoS mark 5
    -- Called SIP/101
    -- Called SIP/102
    -- Called SIP/103
    -- Connected line update to DAHDI/1-1 prevented.
    -- Connected line update to DAHDI/1-1 prevented.
    -- Connected line update to DAHDI/1-1 prevented.
    -- SIP/101-00000004 is ringing
    -- SIP/102-00000005 is ringing
    -- SIP/103-00000006 is ringing
    -- Nobody picked up in 20000 ms
    -- <DAHDI/1-1>AGI Script sarkhpe completed, returning 0
    -- Channel 'DAHDI/1-1' sent to invalid extension: context,exten,priority=extensions,510,1
    -- Executing [i@extensions:1] PlayTones("DAHDI/1-1", "congestion") in new stack
    -- Auto fallthrough, channel 'DAHDI/1-1' status is 'NOANSWER'
    -- Hanging up on 'DAHDI/1-1'
    -- Hungup 'DAHDI/1-1'
    -- Starting simple switch on 'DAHDI/1-1'
    -- Executing [s@from-pstn:1] Set("DAHDI/1-1", "chan=1-1") in new stack
    -- Executing [s@from-pstn:2] Set("DAHDI/1-1", "chan=1") in new stack
    -- Executing [s@from-pstn:3] Goto("DAHDI/1-1", "mainmenu,DAHDI1,1") in new stack
    -- Goto (mainmenu,DAHDI1,1)
    -- Channel 'DAHDI/1-1' sent to invalid extension: context,exten,priority=mainmenu,DAHDI1,1
    -- Executing [i@mainmenu:1] Goto("DAHDI/1-1", "extensions,500,1") in new stack
    -- Goto (extensions,500,1)
    -- Executing [500@extensions:1] AGI("DAHDI/1-1", "sarkhpe,Alias,SIP/101&SIP/102&SIP/103,500,") in new stack
    -- Launched AGI Script /usr/share/asterisk/agi-bin/sarkhpe
    -- AGI Script Executing Application: (Dial) Options: (SIP/101&SIP/102&SIP/103,20,ciIkt)
  == Using SIP RTP CoS mark 5
  == Using SIP RTP CoS mark 5
  == Using SIP RTP CoS mark 5
    -- Called SIP/101
    -- Called SIP/102
    -- Called SIP/103
    -- Connected line update to DAHDI/1-1 prevented.
    -- Connected line update to DAHDI/1-1 prevented.
    -- Connected line update to DAHDI/1-1 prevented.
    -- SIP/101-00000007 is ringing
    -- SIP/102-00000008 is ringing
    -- SIP/103-00000009 is ringing
    -- <DAHDI/1-1>AGI Script sarkhpe completed, returning 4
  == Spawn extension (extensions, 500, 1) exited non-zero on 'DAHDI/1-1'
    -- Hanging up on 'DAHDI/1-1'
    -- Hungup 'DAHDI/1-1'


I've probably done something accidental to cause this problem, but I have no idea what. Any clues?

Many thanks
David

Ahhh... no! Will try and report back.

Hello all and happy new year

I'm trying to get a handset up and running over a site-to-site VPN.

The IP address of the SAIL box is 192.168.200.20, with the gateway/router on the main network being 192.168.200.1.

The IP address of the handset is 192.168.250.107 (DHCP) with the gateway/router on the remote client network being 192.168.250.1.

(phone) 192.168.250.107 <--> 192.168.250.1 <--[VPN tunnel]--> 192.168.200.1 <--> 192.168.200.20 (SAIL)

I've added matching rules into the SAIL firewall for the network 192.168.250.0/24 (copied from net$LAN), and as a result provisioning works fine, with the handset reaching out over the VPN and getting its config. However, when the SIP account goes to register, the handset (a Yealink) shows "Registration failed". No relevant events that I can see are showing up in the SAIL logs (although maybe I'm not looking in the right place?). I can confirm that I can ping the handset over the VPN from the main site.

Does anyone have any suggestions about what might be going wrong and how I can troubleshoot further?

Many thanks!
David

Very odd. I'm not sure why you're seeing an extension save error, because all the work is done in the templates. Selintra, any clues?

Regarding Yealink autodetection, will that interfere with the ability to add newer models into the SAIL templates list as they come out?

Thanks for keeping on this one folks. Much appreciated.

Hi Selintra

Quick question. I have a site which used to have a super old ISDN based PBX, and they are used to being able to pick up a call on a "line" (specific circuit) from other handsets rather than transferring said call between handsets.

They are looking for this functionality in Asterisk, and I haven't been able to figure out exactly how to do this. The closest idea I've had is to give them the code to pick up a call currently on hold on another handset, but when I tried to test this idea out I couldn't make this work (*8401 just gave a denied error).

Any clues as to what I'm missing?

Many thanks

I made some commits and they are turning up as expected.

Necessity is the mother of all invention

The good thing about the Yealinks is that when the documentation isn't clear, you can input the desired settings into the phone's web interface and then export the configuration file to reveal the correct syntax.

Hi all

I've been playing around with Yealink provisioning, and noticed that although LDAP supported is enabled in the default templates, we can't set up LDAP as an enabled directory without further changes.

First, we'll need to add the following to the yealink.Common template:


# turn on ldap
ldap.enable = 1

# customise directory lookups
directory_setting.url = http://$localip/provisioning/favorite_setting.xml
super_search.url = http://$localip/provisioning/super_search.xml


We'll now need to create these two templates, each by clicking the + sign (top right of the Templates screen) and entering the following:

• Device: filename (see below)
• Technology: Custom
• Copy: New
• Description: (see below)

We'll need two extra files.

1. favorite_setting.xml - Yealink Favourite Template


<root_favorite_set>
        <item id_name="ldap" display_name="LDAP" priority="1" enable="1" dev="common" />
        <item id_name="localdirectory" display_name="Local Directory" priority="2" enable="1" dev="common" />
        <item id_name="history" display_name="History" priority="3" enable="0" dev="common" />
        <item id_name="networkcalllog" display_name="Network CallLog" priority="4" enable="0" dev="common" />
        <item id_name="remotedirectory" display_name="Remote Phone Book" priority="5" enable="0" dev="common" />
        <item id_name="networkdirectory" display_name="Network Directories" priority="6" enable="0" dev="common" />
</root_favorite_set>


This file controls the "DIR" button on your phone's home screen. By default, only the local directory is shown. This adds the LDAP directory as the first entry.

2. super_search.xml - Yealink Search Template


<root_super_search>
        <item id_name="ldap_search" display_name="LDAP" priority="1" enable="1" />
<item id_name="local_directory_search" display_name="Local Contacts" priority="2" enable="1" />
<item id_name="calllog_search" display_name="History" priority="3" enable="1" />
<item id_name="remote_directory_search" display_name="Remote Phone book" priority="4" enable="0" />
<item id_name="Network_directory_search" display_name="Network Directories" priority="5" enable="0" />
</root_super_search>


This file controls the instant search which is available while dialling. By default, the phone's dial history and the local directory are shown. This adds the LDAP directory into the source list as well.

Hi Selintra

I noticed that after installing -30 on a fresh install, the /opt/sark/bkup and /opt/sark/snap folders are missing.

Creating the two folders allows backups to work, but I've yet to see a snapshot created (the system is largely complete, so maybe that's why).

Cheers
David

This is a short tutorial about backing up SAIL to a NAS drive over NFS. I've used a QNAP NAS as the example.

1. First, we'll need to turn on NFS on the QNAP and enable NFS access for the specific share you'll be using. The instructions will vary by device and firmware version, but you can get the idea at http://docs.qnap.com/nas/4.3/cat2/en/win_mac_nfs.htm and http://docs.qnap.com/nas/4.3/cat2/en/file_station.htm. I recommend you create an ACL which permits access only from the specific SAIL host.
2. Now we can add the mount point on the SAIL server and set up NFS access. To begin, let's create the mountpoint used by the backup manager tool:

sudo mkdir /var/archives

3. Now we can test that the NFS mounting works. Replace 10.0.0.20 with the IP address of your NAS device, and pbx_backup with the share you created in Step 1:

sudo mount -t nfs 10.0.0.20:/pbx_backup /var/archives

4. Let's test write access:

sudo touch /var/archives/testfile

You can now browse your NAS share from elsewhere and check that the file is present.
5. If mounting and writing works, it's time to add the NFS share to your /etc/fstab so it's automatically mounted on boot.

sudo nano /etc/fstab

Let's add the following to the file:

# NAS1 backup
10.0.0.20:/pbx_backup   /var/archives  nfs     defaults        0       0

6. Reboot the server and repeat the test from step 4.
7. Now we can install backup-manager, the simple tool we will be using to handle the backups:

sudo apt-get install backup-manager backup-manager-doc

When prompted for locations to backup, you can keep the default folders (/etc and /home), and add the following: /opt/sark/db /var/spool/asterisk /opt/sark/bkup /opt/sark/snap
8. We now need to disable SCP upload, which is enabled by default. This is done from the /etc/backup-manager.conf file. As this is pretty big, we'll figure out what line we need to edit in advance:

sudo grep -n scp /etc/backup-manager.conf

We can then go straight to that line with nano (replace 300 with the output from grep -n)

sudo nano +300 /etc/backup-manager.conf

We can now change the "BM_UPLOAD_METHOD" to "none" by modifying the line as follows:

export BM_UPLOAD_METHOD="none"

9. Time to test the backup! Run the following command:

sudo backup-manager

You should see a number of .tar.gz files on your NAS share straight away.
10. Finally, we can automatically back up our system every day by adding the backup-manager command to /etc/crontab, the system scheduler's control file. First, let's open it up:

sudo nano /etc/crontab

Now add the following lines at the bottom of the file:

# backup
0 21 * * * root /usr/sbin/backup-manager >/dev/null 2>&1

Save the file and you're done!

Hi Selintra

Just a quick FYI that I upgraded a Yealink T40P to firmware release T40-54.81.0.70 and it broke auto provisioning (including when I manually inputted the URL). I'm suspecting this was the phone and not SAIL, because downgrading back to the latest 54.80 series worked as expected.

If you would like any particular logs to take a look at please let me know.

Cheers
David

Thanks for that! I noted that the -30 had a bunch of bugs fixed so went ahead and manually installed this.

Hi all

Can someone please advise what the current recommended setup for a new production machine is?

4.1 on Jessie/v7?
4.1 on Wheezy/v8?
or 5.0 on Wheezy?

Thanks