SAIL Community Supported PBX

I was going to take a look at the v6 beta but ran into an issue installing sail

The following packages have unmet dependencies:
sail : Depends: sailhpe but it is not installable
E: Unable to correct problems, you have held broken packages.

I tried to install sailhpe, but its not available.  Just FYI - let us know when the package becomes available.

Is there a way of changing this default behaviour?

Did you just say Snom ONE ... that pile of steaming $*%^ !!! I've still got one of those running at a clients and it gives me nothing but trouble!

Thanks for all that ... Spitfire's response so far is

Quote... engineers have advised that we do not accept OPTION messages so the response you are seeing is correct - this should not stop any functionality of the SIP trunk however.

I've gone back to them asking for their SARK engineer to look at this (after all don't they still supply them?)

Nearly 3 months later this has happened again ... I'm engaging with Spitfire but they don't think it's an issue at their end.

The debug on the trunk IP shows :
Reliably Transmitting (no NAT) to 83.218.143.16:5060:
OPTIONS sip:spitfiretsp.net SIP/2.0
Via: SIP/2.0/UDP 192.168.81.200:5060;branch=z9hG4bK4285065a
Max-Forwards: 70
From: "asterisk" <sip:44xxxxxxxxxx@192.168.81.200>;tag=as3822e0a6
To: <sip:spitfiretsp.net>
Contact: <sip:44xxxxxxxxxx@192.168.81.200:5060>
Call-ID: 1e07ba343b9f86836798f2a27ef2e7db@192.168.81.200:5060
CSeq: 102 OPTIONS
User-Agent: Asterisk PBX 11.13.1~dfsg-2+deb8u2
Date: Fri, 26 Jan 2018 10:17:06 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Length: 0


---

<--- SIP read from UDP:83.218.143.16:5060 --->
SIP/2.0 202 Not understood
Via: SIP/2.0/UDP 192.168.81.200:5060;received=46.102.214.214;branch=z9hG4bK4285065a;rport=50628
From: <sip:44xxxxxxxxxx@192.168.81.200>;tag=as3822e0a6
To: <sip:spitfiretsp.net>;tag=9d9d1304547cf9dc5dd59d58f131aae1.b9a3
Call-ID: 1e07ba343b9f86836798f2a27ef2e7db@192.168.81.200:5060
CSeq: 102 OPTIONS
Content-Length: 0

<------------->
--- (7 headers 0 lines) ---
Really destroying SIP dialog '1e07ba343b9f86836798f2a27ef2e7db@192.168.81.200:5060' Method: OPTIONS

As stated previously, Spitfire state the trunk is not registered.

I did a little more digging, and am not sure if what I am seeing is correct - there seem to be 3 active channels here to Spitfire ?

sip show channels
Peer             User/ANR         Call ID          Format           Hold     Last Message    Expiry     Peer
192.168.81.46    (None)           2d000000eb59-dq  (nothing)        No       Rx: REGISTER               <guest>
83.218.143.16    44xxxxxxxxxx     b377e504-5925-1  (alaw)           No       Rx: ACK                    44203696xx
83.218.143.16    44xxxxxxxxxx     38c68dee-79fd-1  (alaw)           No       Rx: ACK                    44203696xx
83.218.143.16    44xxxxxxxxxx     71aa9a11-5485-1  (alaw)           No       Rx: ACK                    44203696xx
4 active SIP dialogs

The active channels persist even after I disabled the trunk via the web interface.

I then turned off debugging and went back into the CLI with logging on 4, and my session immediately filled with repeating scrolling output, a sample of which is Connected to Asterisk 11.13.1~dfsg-2+deb8u2 currently running on SARK (pid = 1223)
SARK*CLI>
    -- AGI Script Executing Application: (Set) Options: (CDR(userfield)=_XXXX.)

SARK*CLI>
    -- <SIP/44203696xxxx-000008f1>AGI Script sarkhpe completed, returning 0

SARK*CLI>
    -- Executing [44203696xxxx@from-trunk:2] Set("SIP/44203696xxxx-000008f1", "parseDDI=") in new stack
    -- Executing [44203696xxxx@from-trunk:3] Goto("SIP/44203696xxxx-000008f1", "from-trunk,,1") in new stack
    -- Goto (from-trunk,44203696xxxx,1)
    -- Executing [44203696xxxx@from-trunk:1] AGI("SIP/44203696xxxx-000008f1", "sarkhpe,Inbound,_XXXX.,,") in new stack
    -- Launched AGI Script /usr/share/asterisk/agi-bin/sarkhpe

SARK*CLI>
    -- <SIP/44203696xxxx-00001743>AGI Script sarkhpe completed, returning 0

SARK*CLI>
    -- Executing [44207720xxxx@from-trunk:2] Set("SIP/44203696xxxx-00001743", "parseDDI=") in new stack
    -- Executing [44207720xxxx@from-trunk:3] Goto("SIP/44203696xxxx-00001743", "from-trunk,,1") in new stack
    -- Goto (from-trunk,44207720xxxx,1)
    -- Executing [44207720xxxx@from-trunk:1] AGI("SIP/44203696xxxx-00001743", "sarkhpe,Inbound,_XXXX.,,") in new stack
    -- Launched AGI Script /usr/share/asterisk/agi-bin/sarkhpe

SARK*CLI>
    -- <SIP/44203696xxxx-00000bbd>AGI Script sarkhpe completed, returning 0

SARK*CLI>
    -- Executing [44207720xxxx@from-trunk:2] Set("SIP/44203696xxxx-00000bbd", "parseDDI=") in new stack
    -- Executing [44207720xxxx@from-trunk:3] Goto("SIP/44203696xxxx-00000bbd", "from-trunk,,1") in new stack
    -- Goto (from-trunk,44207720xxxx,1)
    -- Executing [44207720xxxx@from-trunk:1] AGI("SIP/44203696xxxx-00000bbd", "sarkhpe,Inbound,_XXXX.,,") in new stack
    -- Launched AGI Script /usr/share/asterisk/agi-bin/sarkhpe

SARK*CLI>
    -- AGI Script Executing Application: (Set) Options: (CDR(userfield)=_XXXX.)

SARK*CLI>
    -- AGI Script Executing Application: (Set) Options: (CDR(userfield)=_XXXX.)

SARK*CLI>
    -- AGI Script Executing Application: (Set) Options: (CDR(userfield)=_XXXX.)

SARK*CLI>
    -- <SIP/44203696xxxx-000008f1>AGI Script sarkhpe completed, returning 0

SARK*CLI>
    -- Executing [44203696xxxx@from-trunk:2] Set("SIP/44203696xxxx-000008f1", "parseDDI=") in new stack
    -- Executing [44203696xxxx@from-trunk:3] Goto("SIP/44203696xxxx-000008f1", "from-trunk,,1") in new stack
    -- Goto (from-trunk,44203696xxxx,1)
    -- Executing [44203696xxxx@from-trunk:1] AGI("SIP/44203696xxxx-000008f1", "sarkhpe,Inbound,_XXXX.,,") in new stack
    -- Launched AGI Script /usr/share/asterisk/agi-bin/sarkhpe

SARK*CLI>
    -- <SIP/44203696xxxx-00001743>AGI Script sarkhpe completed, returning 0

SARK*CLI>
    -- Executing [44207720xxxx@from-trunk:2] Set("SIP/44203696xxxx-00001743", "parseDDI=") in new stack
    -- Executing [44207720xxxx@from-trunk:3] Goto("SIP/44203696xxxx-00001743", "from-trunk,,1") in new stack
    -- Goto (from-trunk,44207720xxxx,1)
    -- Executing [44207720xxxx@from-trunk:1] AGI("SIP/44203696xxxx-00001743", "sarkhpe,Inbound,_XXXX.,,") in new stack
    -- Launched AGI Script /usr/share/asterisk/agi-bin/sarkhpe

SARK*CLI>
    -- <SIP/44203696xxxx-00000bbd>AGI Script sarkhpe completed, returning 0

SARK*CLI>
    -- Executing [44207720xxxx@from-trunk:2] Set("SIP/44203696xxxx-00000bbd", "parseDDI=") in new stack
    -- Executing [44207720xxxx@from-trunk:3] Goto("SIP/44203696xxxx-00000bbd", "from-trunk,,1") in new stack
    -- Goto (from-trunk,44207720xxxx,1)
    -- Executing [44207720xxxx@from-trunk:1] AGI("SIP/44203696xxxx-00000bbd", "sarkhpe,Inbound,_XXXX.,,") in new stack
    -- Launched AGI Script /usr/share/asterisk/agi-bin/sarkhpe

SARK*CLI>
    -- AGI Script Executing Application: (Set) Options: (CDR(userfield)=_XXXX.)

SARK*CLI>
    -- AGI Script Executing Application: (Set) Options: (CDR(userfield)=_XXXX.)

SARK*CLI>
    -- AGI Script Executing Application: (Set) Options: (CDR(userfield)=_XXXX.)

SARK*CLI>
    -- <SIP/44203696xxxx-000008f1>AGI Script sarkhpe completed, returning 0

SARK*CLI>
    -- Executing [44203696xxxx@from-trunk:2] Set("SIP/44203696xxxx-000008f1", "parseDDI=") in new stack
    -- Executing [44203696xxxx@from-trunk:3] Goto("SIP/44203696xxxx-000008f1", "from-trunk,,1") in new stack
    -- Goto (from-trunk,44203696xxxx,1)
    -- Executing [44203696xxxx@from-trunk:1] AGI("SIP/44203696xxxx-000008f1", "sarkhpe,Inbound,_XXXX.,,") in new stack
    -- Launched AGI Script /usr/share/asterisk/agi-bin/sarkhpe

SARK*CLI>
    -- <SIP/44203696xxxx-00001743>AGI Script sarkhpe completed, returning 0

SARK*CLI>
    -- Executing [44207720xxxx@from-trunk:2] Set("SIP/44203696xxxx-00001743", "parseDDI=") in new stack
    -- Executing [44207720xxxx@from-trunk:3] Goto("SIP/44203696xxxx-00001743", "from-trunk,,1") in new stack
    -- Goto (from-trunk,44207720xxxx,1)
    -- Executing [44207720xxxx@from-trunk:1] AGI("SIP/44203696xxxx-00001743", "sarkhpe,Inbound,_XXXX.,,") in new stack
    -- Launched AGI Script /usr/share/asterisk/agi-bin/sarkhpe

SARK*CLI>
    -- <SIP/44203696xxxx-00000bbd>AGI Script sarkhpe completed, returning 0

SARK*CLI>
    -- Executing [44207720xxxx@from-trunk:2] Set("SIP/44203696xxxx-00000bbd", "parseDDI=") in new stack
    -- Executing [44207720xxxx@from-trunk:3] Goto("SIP/44203696xxxx-00000bbd", "from-trunk,,1") in new stack
    -- Goto (from-trunk,44207720xxxx,1)
    -- Executing [44207720xxxx@from-trunk:1] AGI("SIP/44203696xxxx-00000bbd", "sarkhpe,Inbound,_XXXX.,,") in new stack
    -- Launched AGI Script /usr/share/asterisk/agi-bin/sarkhpe

SARK*CLI>
    -- AGI Script Executing Application: (Set) Options: (CDR(userfield)=_XXXX.)

SARK*CLI>
    -- AGI Script Executing Application: (Set) Options: (CDR(userfield)=_XXXX.)

SARK*CLI>
    -- AGI Script Executing Application: (Set) Options: (CDR(userfield)=_XXXX.)

Obviously I'm not an expert, but is it possible there is some sort of issue occurring with the trunk config, causing the SARK to get stuck in a loop?

I did a graceful restart of asterisk which stopped the output cycling on the screen, re-enabled the trunk and everything appears to be fine now for the time being.

Sorry for the late reply, I didn't subscribe to the topic.

The issue occurred again this morning (more frequent now it appears) so I was able to investigate further.  Spitfire claim that they are not receiving a registration request from the pbx.  Spitfire operate what they call a VRF - effectively they lock the SIP registration to their network, but this particular trunk runs on a (leased line) circuit we supply so Spitfire have added the IP to their VRF range.

Is there anything further I should do the next time this occurs before I disable/re-enable the trunk (which fixes the issue) to try and isolate what might be causing this.

MTIA

I should add, setting the trunk to not active, then switching it back to active gets the trunk working again.

I have an irregular problem with a Spitifre trunk on a SARK (5.0.0.32).  The SARK web interface shows the trunk is up, but Spitfire state they are not seeing any registration requests.  This seems to happen every couple of months.

However looker at the CLI I see

sip show registry
Host                                    dnsmgr Username       Refresh State                Reg.Time
spitfiretsp.net:5060                    N      4420xxxxxxx        75 No Authentication    Tue, 14 Nov 2017 23:39:56

Any ideas why this should occur?

MTIA

I've just seen your post - I have multiple sites configured with remote extensions  (Snom's) running over VPN's

I would set the extension up as a remote extension and remove the localnet entry for the remote network.

Thanks, but it wasn't necessary to enable tenants to make this work. However its not possible to set a single FKey LED colour value - only globally for the Snom phones.

Sorry to answer my own question - yes that did work blf=default sets the blf to open/closed throw.

I'm using Snom's and ideally I'd like to have a green LED for open rather than no LED ... I'll go and have a fiddle!

I see reference to setting a blf as an Open/Closed throw switch but can't seem to find any specific detail on how to do this?  In one of the SAIL 4 releases there is mention of setting the blf to the tenant name (but have tenants disappeared in 5 as I can't see them?)  - so should i set the blf to default for the master tenant ?

Hi all,

I have a client for who I'm installing a new system and they have a peculiar requirement that they want replicated from their existing system - but I can't think how this can be done!

They have the ability to toggle withholding their caller ID from and reflecting the status of this on a BLF currently - so if (outbound) callerID is withheld the BLF is lit and if not its not lit.  I'm using Snom handsets for the new system.

Our SIP provider supports the 141 prefix to withhold the callerID.

I can't see a way of selecting an outbound route from the SIP client or assigning that to a BLF?

My only idea so far is to use multi-tenant on the SARK and register the phones with two identities to each tenant but then switching between the identities on the Snom phones isn't very elegant.

Any thoughts / suggestions would be gratefully appreciated.