Topic: SAIL -414

[SARK devs]

Oops - thanks for spotting this!

Yes - you are quite correct - it does.  Sam made an edict sometime around -360 that we wouldn't allow *number* in user code in case we introduce a new preset that conflicts with something you guys have done on your own sites.  It should have been changed in the Wiki and never was.

We could still allow it if it is going to cause you guys problems - it's not a huge change.  We would prefer not to but this is a democratic product and the input from you all has been invaluable so let me know what you think and we'll decide over the weekend.  What we would like to recommend is that you use a regular 1,2, or 3 digit number for your custom presets.

Apologies to everyone - we don't always get it right; SAIL is a big old beast now and even we sometijmes forget how it's supposed to work!

 

[hervep]

Oops - thanks for spotting this!

Yes - you are quite correct - it does.  Sam made an edict sometime around -360 that we wouldn't allow *number* in user code in case we introduce a new preset that conflicts with something you guys have done on your own sites.  It should have been changed in the Wiki and never was.

We could still allow it if it is going to cause you guys problems - it's not a huge change.  We would prefer not to but this is a democratic product and the input from you all has been invaluable so let me know what you think and we'll decide over the weekend.  What we would like to recommend is that you use a regular 1,2, or 3 digit number for your custom presets.

Apologies to everyone - we don't always get it right; SAIL is a big old beast now and even we sometijmes forget how it's supposed to work!

 

... No problem at all

To answer to the question, arround possible choices, I would suggest to
fix some prefix to be used with custom-apps, without limiting the amount of digits that follows.

Why ... just because it is (to my opinion ) a good way to 'hide' some function to the user.

Practical example : currently, I have a cust app (*998*) that sends a report/backup of the system to a predefined mail address. Goal is to facilitate 'helpdesk' action in case of question/issue of one of my friends using Sail. Imagine the same situation with some 'customer' ... Might be interresting to 'hide' the code, using enough complexity ( i.e. ***123456789# ) for the common user. Only the system manager should be aware of it.

Code: [Select]

#!/bin/sh

# *remobackup*.sh
# Generates a 'backup' of sail configuration.
# Report is sent by mail ( MAY CONTAIN PRIVATE/CONFIDENTIAL DATA )

# You can enable the script by adding some 'SAIL' custom application like :
# ; script that sends config data of Mr Bean ... assuming script *remobackup*.sh into /etc/asterisk-scripts.
# exten => *998*,x,System(/etc/asterisk-scripts/*remobackup*.sh)


# config
mailaddress="tomailadd@somewhere.net"
servername="Mr Bean"
# end config

# let's compress needed stuffs ... you can add what you want/need.
/bin/tar -czf  /tmp/configuration.tgz /etc/asterisk/*
/bin/tar -czf  /tmp/selintra-work.tgz /home/e-smith/db/selintra-work

# Send everything via mail to the address specified in 'mailaddress'
echo "Asterisk configuration files from "$servername" attached" | mutt -s "Asterisk "$servername" backup and config files" -a /tmp/configuration.tgz -a /tmp/selintra-work.tgz $mailaddress

# remove the temporary files
rm /tmp/configuration.tgz
rm /tmp/selintra-work.tgz

# end script

Another possible purpose is to simulate some 'access code/pin code' giving an external line to some users on sets that are not supposed to call to the outside.  I did'n tryied this yet, but quite sure it is possible. Again, this code has to be seen as 'secret' code, with enough complexity, for common users.

Just for your info : *xxx* cust_app access works perfectly using Sail -414.

Kind regards and many thanks !.

Hervé

[SARK devs]

Hi Herve

OK -- we'll go with that (which saves us changing the docs...).  I'll revert to the -414 generator fragments.  These will allow *NNN* or simple numbers for your presets.

I'll run some tests this afternoon and you can probably have it this evening.

btw - I really like your idea of sending e-mail reports as a result of a key press at the phone.  It would be a really nice feature (and not hard to do if anyone would like to volunteer) to send people a formatted list of their day's calls "on demand".   The e-mail address associated with the phone is at...

either (old-style)

 db_get_prop(\%selintra, {phone-extension}, 'vmail')

or (object)

 $DB->get_prop({phone-extension}, 'vmail')

CDR's are in /var/log/astrisk/cdr-csv/Master.csv

Just grep the rows we need and off we go...

too cool for school!



J

[SARK devs]

There you go....

I've just put -419 up.  It should handle your *999* feature codes correctly.

Best

J

[hervep]

Hi Selintra

... Nothing urgent ! Take your time ... even in the UK it should be weekend

I had the same idea arround giving 'tools' to the user to modify/see own data. Sending emails 'on-demand' with cdr reporting sounds good to me.

First idea I had was to make some basic PHP portal, giving each user the ability to change/see 'own' settings :

- See own cdr ( based on pre-tests V3 Sail only - Mysql )
- Modify Follow-me conditions, nr's ...
- Modify personal data ( Name , email address, all kind of stuff like that ... ).

A very very first test arround cdr ( MYSQL ONLY ) I made was the following ( V3 ONLY ):

( Just drop cdr.php into primary html, edit $callfrom as needed ...)

Code: [Select]

<html>
<head>
<title>QUICK CDR View</title>
</head>
<body bgcolor="white">
<?php
/*
require_once&#40;"config.php"&#41;;
*/
$callfrom = '5000';
$database = mysql_connect&#40;"localhost", "asterisk", "aster1sk"&#41;;
mysql_select_db&#40;"asterisk"&#41;;
$query = "SELECT calldate,clid,dst,duration,disposition FROM cdr WHERE clid =\"$callfrom\" ORDER BY calldate DESC LIMIT 20";
$result = mysql_query&#40;$query&#41;;
echo "<a href=\"cdr.php\">Click here</a> to refresh";
echo "<br><br>";
echo "<table border=\"0\">";
echo "<td bgcolor=\"#FFFFAA\">DATE    TIME<td bgcolor=\"#FFFFAA\">CALLER<td bgcolor=\"#FFFFAA\">CALLED<td bgcolor=\"#FFFFAA\">DURATION<td bgcolor=\"#FFFFAA\">STATUS</td>";
$j = true;
while &#40;$row = mysql_fetch_row&#40;$result&#41;&#41; &#123;
    if &#40;$j&#41;
        $j = false;
    else
        $j = true;
    echo "<tr>";
    for &#40;$i = 0;$i < mysql_num_fields&#40;$result&#41;;$i++&#41; &#123;
        if &#40;$j&#41; &#123;
            echo "<td bgcolor=\"#FFFFBB\">";
        &#125;
        if &#40;!$j&#41; &#123;
            echo "<td bgcolor=\"#FFFFCC\">";
        &#125;
        echo $row[$i&#93;;
        echo "</td>";
    &#125;
&#125;
echo "</table>";
mysql_close&#40;$database&#41;;

?>
</body>
</html>

Best,

Hervé

[hervep]

There you go....

I've just put -419 up.  It should handle your *999* feature codes correctly.

Best

J

It works

Many thanks & good weekend !

Hervé

[SARK devs]

HI Herve

This is really cool.  I also had been thinking that we need a  "user" portal to provide a simple "do stuff for yourself" interface that an end-user could handle without getting into trouble.

I looked at Ruby-on-rails but discounted it;  at the moment I am considering Maypole/Catalyst because it/they are easier to fit, Perl based and follow the MVC model which seems to be enjoying something of a revival at the moment.

The other option would be to go php but I'm not sure how much it gives us over Perl in the real world.

Thoughts?  Ideas?

Best

J

[hervep]

HI Herve

This is really cool.  I also had been thinking that we need a  "user" portal to provide a simple "do stuff for yourself" interface that an end-user could handle without getting into trouble.

I looked at Ruby-on-rails but discounted it;  at the moment I am considering Maypole/Catalyst because it/they are easier to fit, Perl based and follow the MVC model which seems to be enjoying something of a revival at the moment.

The other option would be to go php but I'm not sure how much it gives us over Perl in the real world.

Thoughts?  Ideas?

Best

J

The 'user portal' technology involved is -to my opinion- not the major concern. My idea to do some 'user portal' using php is just because of personal skills.

If I take a look onto the system as it is know, putting my mind in 'professional mode on' instead of ' hobby mode on ' I would prioritise things as follow ( just my input, nothing more than that ! ) :

1) Ability to select amount of digits (2,3,4) for internal range.
This is a major concern for peoples who want to replace some existing PBX. They want to re-use the same internal range.

2) Creation of some integration API layer.
It is almost impossible to have a standard product offering all expectations of customers all over the world. This step makes also easier additional features as the 'user portal', or any specific integration wanted.
The way I would go ( considering what you already did ) is 'mysql'.

==> 'Easy' to import existing customer data (extensions, names, mail, voicemail, passwords, type of set ... based on single csv file )
==> 'Easy' to make customised backup & ready stand-by systems.
==> 'Easy' to make monitoring/alarming tools reading asterisk status based on config 'queries'.
==> 'Easy' odbc 'windows' capabilities for peoples still wanting to use Gates machine.
==> etc ...

My personal feeling is that Sail V3 is the first step to go... .

Just my € cent

Best,

Hervé

[SARK devs]

Hi Herve

Thanks for this.

Funnily enough, number length has not been a problem in the field.  This is because we can replicate whatever they want using aliases.  So if, for example, a customer previously had three digit numbers starting at say extn 201 (very common for some reason), we allocate numbers 5201, 5202 etc, each with an alias;  201, 202 and so on.  This seems to work very well.  What is more of a problem is SAIL's lack of "soft" feature codes allowing us to mimic whatever they had before for call forwards/dnds etc. This is something we will do in the fairly near future.

For your other observations, we agree totally and they (and SER integration) are what drove the V3 initiative.

By the way, I know you've been testing V3 for some time Herve, but for anyone else who's interested - V3 Alpha is now available on our download site.  We'll put some installation instructions up onto the Wiki but it's pretty much standard rpm stuff and you can install it directly over the top of V2.x.

[hervep]

Funnily enough, number length has not been a problem in the field.  This is because we can replicate whatever they want using aliases.  So if, for example, a customer previously had three digit numbers starting at say extn 201 (very common for some reason), we allocate numbers 5201, 5202 etc, each with an alias;  201, 202 and so on.  This seems to work very well.

It is also the way I did it in my 'customer simulation' at home. It is certainly a good way to cover 2 & 3 digits ranges in a single unit.
It becomes a little bit more complicated in case of trunked multi-unit systems ( possible closed Nr sheme conflict with ddi ranges ... )

To make this bypass user friendly, maybe some additional process that creates aliases automatically would be nice.

IE : General settings : Auto alias button giving 2,3,4 digits as choice, 4 digits meaning in fact 'no alias'.
When creating an extension, extension & alias created.

 What is more of a problem is SAIL's lack of "soft" feature codes allowing us to mimic whatever they had before for call forwards/dnds etc. This is something we will do in the fairly near future.

I agree with that, but does it always make sense to copy (all) features of outdated pbx's ? . Some features are important, other may be solved by new thinkings. User panel is a way to improve things, IVR automation also.

- User is at the office or has access to his network ==> User panel.
- User is 'outside' ==> IVR programming.

  IVR example : > give your personal ID code ...
                        (123456789)
                        > Morning Mister Selintra,
                        - 1 Extension relation modification
                        - 2 Personal announcement
                        - 3 Voice mail
                        - 4 Presence status
                        - 5 ...
                        (1) Was chosen
                        > Which extension do you want to update
                        (5000) Was given
                        - 1 for CFNR
                        - 2 for CFDA
                        - 3 for CFBE
                        - 4 for DND

                         ... and so on.

- Sets offering 'browser' or 'xml' stuffs may also be use as recommended terminal for some paticular needs ...

 Internal/external name directory 'browsing' is a good example.

V3 Alpha is now available on our download site.  We'll put some installation instructions up onto the Wiki but it's pretty much standard rpm stuff and you can install it directly over the top of V2.x.

... hmmm where exactly ? not in 'pre-releases' ...

Thanks for all the things you are doing !

Best,

Hervé

[SARK devs]

Thanks Herve,

These are really cool ideas (which we will unashamedly steal for SAIL - ) - thank you very much for sharing them with us.

Look in Rev3 for latest V3.0 release.

Best

J

[SARK devs]

Hi all

We've put some of Herve's ideas into selintra-sail-2.1.14-425.noarch.rpm which you can get from the usual place.

ftp://81.149.154.14/Pre-Releases

There is one new entry in globals...  an administrator email address (you need to fill it out for some of this stuff to work).  There are three new feature codes you can run from your phone...

*901* will create a backup of the SAIL data and e-mail it to the administrator address (see above)
*902* will reload asterisk
*903* will email a report of the day's CDR's for the extension at which you enter the feature code.  It will be mailed to the email address defined in the extension or, if there isn't one, to the administrator address.  It could do with cleaning up a bit but it's OK for a first attempt.

We might do a few more depending upon how the mood takes us.  


Kind Regards

Selintra

[sonoracomm]

Looking good.  I upgraded one server without issue.

The new tools are interesting and worked as advertised.  I could see this little collection of utilities growing...

I may try to tweak the CDR report when I get some free time...

Thanks much,

G

[SARK devs]

I may try to tweak the CDR report when I get some free time...

Please do...

It could have weekly & monthy views, a password protected version so that a supervisor can decide which extension to view, a global view which sends  "all calls" reports to the supervisor.  

The perl code isn't complex and the CDR's are easy enough to grep.

Have fun

Best

selintra

[psoren]

*901* will create a backup of the SAIL data and e-mail it to the administrator address (see above)
*902* will reload asterisk
*903* will email a report of the day's CDR's for the extension at which you enter the feature code.

This works well. Maybe it's worth to mention that one might have to add to dial plans to make it work.
In my Sipura i now have: (*x.|*xx*x.|x.|*90[123]*) (Other suggestions?)

We might do a few more depending upon how the mood takes us.

YES!! Give us more......


Per