SAIL Community Supported PBX

 

Dynamic features doesn't have anything to do with this I'm afraid.   

One-way or no audio is almost always caused by NAT traversal issues.   Before you do anything else, ensure your local router has all SIP ALG's or SIP "assists" turned off.   Routers, both expensive and cheap, invariably screw up SIP NAT traversal so make sure yours isn't messing with the packets. 

You don't say if this is a direct call to the cell or a diverted call.   In any event, check the following...

1.  Ensure you have set the correct public IP address for your PBX in SARK.   Pre V6 this was done in the Globals panel and you had to set it manually.  In V6, SARK figures it out for itself but you can override it (in the network panel) if you have a local network with more than one public IP and you want to control which will use SIP.

2.  On diverted and twinned calls the two SIP endpoints can get into a race condition where each is waiting for the other to speak first in order to establish symmetrical RTP.   You can usually avoid this by forcing Asterisk to take the initial call off hook before making the outbound dial.   To do that, set "Late Termination" in Globals to NO (V5) or toggle it OFF (V6)

3. Sometimes, when (2) doesn't work, you have to make yourself the first speaker.   To do this turn on call progress in the SIP trunk you are using to carry the call.

Usually one of these.   

As an aside, to fix the DYNAMIC features message, uncomment the automon feature in asterisk->sark_features_featuremap.conf (assuming you want to implement automon, if not, you can just ignore the message).

 

By hard coded, I simply meant a hard value in the callerID field of the extension (Extension->Edit->Outbound Caller ID).  :-)

SARK won't change a callerID unless you ask it to.   There are several places where this can be done; in the extension, in the tenant or in the trunk definition.   If any of these have a CLID then it will be used.

You can verify this by running agi debug at the asterisk console.   If SARK makes a change then it will show up in the trace.   It will show up looking like this

<Local/07nnnnnnnn@internal-00000031;2>AGI Rx << EXEC Set CALLERID(number)=01924nnnnnn
-- AGI Script Executing Application: (Set) Options: (CALLERID(number)=01924nnnnnn)

It's also worth noting that your SIP carrier may not allow you to send a CLID which you don't own, in which case they will usually just override it with the CLID (DDI) associated with the trunk you are sending on.

I just ran a test here on a V6.0.1-51 image with no CLID explicitly set and it sent the originating CLID to my cellphone, which was twinned with my extension.

If it still isn't working for you, let me know the SARK release and send me a console log of the call arriving and leaving the PBX

Yep, I noticed the sounds pack a day or two after I posted this.   I've moved a copy into the repo so I think you should be all good now.   
   

Under normal circumstances it will indeed send the originating CLID unless you have a hard coded value in the CLID field of your extension definition, in which case it will send that instead (see the help paragraph under that field entry in the V6 extension->edit panel).    Usually, you should leave the extension CLID value blank unless you want to send a specific DiD to the callee. 

OK, well, we'll keep it under review but it's a great deal of work to provide a general purpose stats pack. There's a lot of other work going on in the background at the moment with the whole back-end of the product being decoupled into a formal API.  This will allow us more flexibility in the presentation layer so you may see something mid-term.    Glad you like the V6 layout.  Did you try running it on a tablet or smartphone yet?  It's pretty cool in the way it adapts to differing screen sizes and layouts.

wow!  You did a lot of work. 

OK, let's see.   Which release of 6 are you running?  I wasn't aware of issues with internal calls not showing up.  I'm assuming you are talking about the recordings browser component, not the underlying data.  Yes?

In terms of conference rooms and call recording, we took a slightly different path to you.  To be fair, it's quite rare we get asked for conference recording so it hasn't been a high priority but here's how we do it when asked.  We use a custom app and we record the conferences to a different directory to the regular recordings.  This makes it somewhat easier to deal with them when it comes to offloading to the final recordings directory which in our customer base is usually some kind of LAN addressed storage.

Bear in mind, customers don't always want recording to be turned on for a particular conference room so we wanted to give them the choice.   So, what we did was to come up with a conference room prefix which the customer could dial to start a conference with call recording enabled.  Here's an example from a customer who has 6 conference rooms; 2894, 2895, 2896, 2897, 2898 and 2899.   What we have is an app which uses a prefix (in this case 2) to invoke the conference with recording enabled, e.g. 22894, 22895 and so on. Here it is


exten=>_2289[4-9],1,SET(CONFBRIDGE(bridge,record_conference)=yes)
exten=>_2289[4-9],n,SET(CONFBRIDGE(bridge,record_file)=/var/spool/asterisk/confrecordings/${STRFTIME(${EPOCH},,%s)}-confcall-${CALLERID(num)}-${EXTEN:1}.wav)
exten=>_2289[4-9],n,ConfBridge(${EXTEN:1},,sark_hosted_user)
exten=>_2289[4-9],n,HangUp


You can see we invoke the bridge with record_conference=yes which is enough to get call recording done.  However, we also point the recording at a new folder in /var/spool/asterisk called confrecordings and give the file a name the recording browser software will understand.   And that's it for the invocation.  As it turns out, as long as at least one conference attendee uses the prefix, then call recording will work as advertised.

So, now we have a bunch of recordings in our new folder confrecordings.  To deal with them we use a new cron mover to ship them off to the final recordings directory.   You can run it as often as you like but we tend to run it once an hour.  Here is how it looks


#!/bin/bash
logger "checking share..."
if ! mount | grep "on /mnt/callrecordings" > /dev/null; then
        logger "share not mounted - Mounting share at /mnt/callrecordings"
        mount -t cifs //some.share/callrecordings -o username=xxxx,password=xxxxx /mnt/callrecordings
        if ! mount | grep "on /mnt/callrecordings" > /dev/null; then
                logger "offload_recordings couldn't mount share - ending"
                exit 8
        fi
fi
# check if there are any files to move...
if find /var/spool/asterisk/confrecordings -maxdepth 0 -empty | read v; then
        logger "no recordings to copy - ending"
        exit 4
fi

#OK, move what we have
logger "beginning conf recordings rsync"
rsync --remove-source-files -a /var/spool/asterisk/confrecordings/* /mnt/callrecordings/`date +%F`/
logger "conf recordings rsync done"
exit 0


As you can see, we just move the file(s) as-is. They look like this, which is compatible with regular recording filenames.


xxxxxx6795-confcall-2238-2894-xxxxxx6805.wav


Now, as you've guessed, it doesn't work very well with tenants, but we are looking at that in V7.  Finally, rsync won't move files that are busy so you can run this as often as you like.

The main benefit I see for this is that it is a bolt-on which shouldn't require any changes to the SARK code itself.

Yes, the CDR is downloadable from the V6 browser.  It is in Settings->Logs
Yes, it is the raw CDR data from /var/log/asterisk/cdr-csv/Master.csv

The billing platform is developed by our sister company Brindley Data Services (www.brindleydata.co.uk). It's called, "Bd-Eye".   You can find information about it on the website.

OK, I think I can shed some light on this.   The deb for buster was missing from the repo.   When I test installed it, I grabbed the deb off the library and installed it in-line so I didn't see the error.   I've just loaded the buster deb into the repo and rehearsed an install.   It went fine so please give it another go and let me know how you get on.   I installed V6 (not V7).   As yet we have no deb for V7 buster.  I'm doing a ton of work on 7 at the moment so it's probably not a good idea to install it for now, although you can if you wish (on stretch).

Somewhat.   We have developed a package on our billing platform but we still haven't decided if/when we'll move it to the PBX.  In the meantime, you can always install the latest Areski stat package from the author, I believe it's called CDR-Stats nowadays. There's no reason why it shouldn't work.   TBH most of our customers are quite happy to simply download the CDRs into Excel or OpenOffice, largely because it gives them more flexibility in formatting and searching the data.  Having said that, we also have a lot of customers running packages like Qmetrics and iSymphony, both of which provide their own stats packs.

I can't take this further without looking at the system.  If it's urgent then call Paul at Brindley and we'll take a look.  As you can imagine we're pretty busy at the moment but we'll get to it as quickly as we can.



 

what version of sail were you attempting to install?

You could install mysqldb before you start the  main install.

These are SAIL admin permissions issues you are hitting.  This can be caused by one of two things.   The first is the permissiond ownership of the sqlite db.   We often see users bringing and old version forward while logged in as root resulting in the db being owned by root.

the file /opt/sark/db/sark.db should look like this


ls -l /opt/sark/db/sark.db
-rw-rw-r-- 1 www-data www-data 540672 Mar 26 07:31 /opt/sark/db/sark.db


Another issue might be that the internal sqlite table UserPanel has the wrong permissions set.   It should look like this


sqlite3 /opt/sark/db/sark.db 'select * from userpanel'
admin|100|create
admin|110|create
admin|115|create
admin|120|create
admin|130|create
admin|134|create
admin|140|create
admin|150|create
admin|160|create
admin|170|create
admin|180|create
admin|190|create
admin|200|create
admin|210|create
admin|215|create
admin|220|create
admin|224|create
admin|230|create
admin|232|create
admin|235|create
admin|236|create
admin|240|create
admin|250|create
admin|252|create
admin|255|create
admin|260|create
admin|265|create
admin|270|create
admin|280|create
admin|290|create
admin|310|create
admin|320|create
admin|330|create
admin|331|create
admin|333|create
admin|335|create
admin|340|create
admin|350|create
admin|370|create
admin|390|create
admin|400|create



Usually one of these two. 

You will need to check that you have not inadvertently set the DB to root ownership.

It should be www-data:www-data

I have seen this a few times and it is usually because a user copied an older DB while logged in as the root user