Topic: Help please

[groutley]

Hi Selintra,
 no idea what I have done, I have been playing a little with my setup, as when I dial a VSP DID I get the VSP voicemail, it never comes thru to Asterisk.
 I have to guess in my playing, I have broken our main extension.
xtn 5000 is our main house phone connected via SPA3102 FXS,
 and our traditional PSTN line comes in via SPA-3102 FXO.

This had all been working wonderfully until today.
all incoming PSTN calls have gone straight to xtn 5000 voicemail.
Investigating this, if I dial 5000  from another extension, the same thing occurs.

I have redirected our incoming PSTN to another extension (5010, my Cisco 7940) and this works fine.
So the SPA3102 FXO / Trunk works fine.
Also the odd thing is that dialing out using the xtn 5000 works fine, and uses VOIP Trunks.

I have played trying to fix,  but cannot see what is wrong.
I don;t know if I broke it, or there is another reason.
appreciate any help..
here is what occurs when I tryto dial xtn 5000

Code: [Select]

    -- Executing Hangup("SIP/5000-b7e05750", "") in new stack
  == Spawn extension (internal, h, 1) exited non-zero on 'SIP/5000-b7e05750'
 Extension Changed 5000 new state Idle for Notify User 5009
    -- Executing AGI("SIP/5009-b7e28760", "selintra|OutCluster|5000") in new stack
 Extension Changed 5009 new state InUse for Notify User 5007
    -- Launched AGI Script /var/lib/asterisk/agi-bin/selintra
    -- AGI Script selintra completed, returning 0
    -- Executing AGI("SIP/5009-b7e28760", "selintra|InCall|") in new stack
    -- Launched AGI Script /var/lib/asterisk/agi-bin/selintra
    -- AGI Script Executing Application: (DBget) Options: (dbVal=STAT/OCSTAT)
    -- DBget: varname=dbVal, family=STAT, key=OCSTAT
    -- DBget: Value not found in database.
    -- AGI Script Executing Application: (DBget) Options: (dbVal=cfimopen/5000)
    -- DBget: varname=dbVal, family=cfimopen, key=5000
    -- DBget: Value not found in database.
    -- AGI Script Executing Application: (DBget) Options: (dbVal=cfim/5000)
    -- DBget: varname=dbVal, family=cfim, key=5000
    -- DBget: set variable dbVal to 5000
    -- AGI Script Executing Application: (Background) Options: (silence/1)
    -- Playing 'silence/1' (language 'en')
    -- AGI Script Executing Application: (Voicemail) Options: (u5000)
    -- Playing 'vm-theperson' (language 'en')
    -- Playing 'digits/5' (language 'en')
    -- Playing 'digits/0' (language 'en')
    -- Playing 'digits/0' (language 'en')
    -- Playing 'digits/0' (language 'en')
    -- Playing 'vm-isunavail' (language 'en')
    -- Playing 'vm-intro' (language 'en')
  == Spawn extension (Home, 5000, 1) exited non-zero on 'SIP/5009-b7e28760'
    -- Executing Hangup("SIP/5009-b7e28760", "") in new stack
  == Spawn extension (Home, h, 1) exited non-zero on 'SIP/5009-b7e28760'
 Extension Changed 5009 new state Idle for Notify User 5007


[SARK devs]

Oh no!!!!!!

You've really done it this time.....

Only joking

Just do *23* at the 5000 phone.  You've got it in call forward immediate to voicemail (DND).


Best

S

[groutley]

Ooooh boy,  do I feel stupid now !!

Thanks for that !  out of curiosity what is the tag that tells you that in the console trace ?

Now in my panic, I had deleted the Trunk and extension related to the SPA-3102,
after redefining I notice that my Xten softphone no longer sees xtn 5000 as available?

is that just as stupid ?

Thanks again

[groutley]

Don't worry,
 restarting the Softphone sorted that one
Thanks for the help.. 

Next to sort out the original problem of the VSP not incoming thru to Asterisk

[SARK devs]

Hi mate

what happens is this....

Call arrives in extensions at wherever....

extensions calls the AGI (incall) and the AGI checks to see if the system is open or closed by retrieving OCSTAT from the DB.  It then looks to see if there are any call forwards on the phone before ringing it.  You can't see the code but you can see the trace of its activity... 

Code: [Select]

    -- AGI Script selintra completed, returning 0
    -- Executing AGI("SIP/5009-b7e28760", "selintra|InCall|") in new stack
    -- Launched AGI Script /var/lib/asterisk/agi-bin/selintra
    -- AGI Script Executing Application: (DBget) Options: (dbVal=STAT/OCSTAT)
    -- DBget: varname=dbVal, family=STAT, key=OCSTAT
    -- DBget: Value not found in database.
    -- AGI Script Executing Application: (DBget) Options: (dbVal=cfimopen/5000)
    -- DBget: varname=dbVal, family=cfimopen, key=5000
    -- DBget: Value not found in database.
    -- AGI Script Executing Application: (DBget) Options: (dbVal=cfim/5000)
    -- DBget: varname=dbVal, family=cfim, key=5000
    -- DBget: set variable dbVal to 5000
    -- AGI Script Executing Application: (Background) Options: (silence/1)
    -- Playing 'silence/1' (language 'en')
    -- AGI Script Executing Application: (Voicemail) Options: (u5000)

The important part to look at is this bit...

Code: [Select]

    -- AGI Script Executing Application: (DBget) Options: (dbVal=cfim/5000)
    -- DBget: varname=dbVal, family=cfim, key=5000
    -- DBget: set variable dbVal to 5000

It's found a CFIM record (call forward immediate) set to 5000.  Hmmmm....  It's set to call forward to itself! ...

We use recursion a lot in our code 'cos it's generally regarded as clever if you're a nerd (the rest of the World just regards it as very very sad). A recursive callforward to self, logically causes the extension to call itself (which will always be engaged) so it will always drop to voicemail, which is in effect, a do-not-disturb.  It doesnt actually call itself but that is the logic.

So there you go.

Best

S

 

[groutley]

Great !
Thanks for that detailed explanation !
would you believe it all makes sense

Wish I knew how I managed to get that CFIM set.

I must be a true nerd,  I remember when cell phones first came out here in Oz.
I tried to call forward my phone to itself,  it was a futile plan to bring down the network,
but would you believe the telco had taken care of the recursive loop.
Well  it didn't bring the network down,  I rust ogt an engaged signal when I rang it !

I guess I just tried it again,  some people never grow up huh 

Thanks again for your quick response and the great explanation.

[SARK devs]

Just to get really nerdish try this....

Setup a call forward loop or spiral with your phones.  For example... CFIM (*21*) 5000=>5001 and then CFIM 5001 => 5000. 

If you want to be really tricksey set up a three or four partner loop .... like this...

5001=>5002=>6000=>5001.

..And maybe add what's known as a spiral to this set-up with 6005=>5002

Then dial into the loop and see what SAIL does with it.



Best

S

 

[groutley]

Hi Selintra,
 think I'll wait till the wife is away for a weekend before I try that one !
I can almost imagine if you played enough you could play a tune with the different rings briefly running around the extensions in the house.

Now, I have been trying to get the SPA3102 provisioning to work,
But it fails..  looking at the syslog from the SPA  I see...

Code: [Select]

Now I am guessing this is due to the following in the generated /tftpboot/spa000e08cb6317.cfg

Code: [Select]

</Resync_Periodic>


</flat-profile>
<Proxy_2_> 192.168.37.251

</Proxy_2_>


this appears to be the merge of spa000e08cb6317line  and spa000e08cb6317pstnline files.
the issue being in the provisioning section for the extension it finishes with

Code: [Select]

</flat-profile>
]and the provisioning section of the trunk does not have any of these XML tags.

So is my thinking correct?
and if so how to fix this, I guess if my thinking is wrong,  how do I fix it anyway

G

[groutley]

But it fails..  looking at the syslog from the SPA  I see...

Code: [Select]

Ooops..  help if I remember to insert the code !!......

Code: [Select]

SPA-3102 00:0e:08:cb:63:17 -- Requesting resync tftp://192.168.37.251:69/spa000e08cb6317.cfg
SPA-3102 00:0e:08:cb:63:17 -- Resync failed: corrupt file
System started: ip@192.168.37.250, reboot reason:H30300010
YM:ERR:AuthServerNotConfig
YM:ERR:AuthServerNotConfig
[0]Reg Addr Change(0) 0:0->c0a825fb:5060
[1]Reg Addr Change(0) 0:0->c0a825fb:5060
SPA-3102 00:0e:08:cb:63:17 -- Requesting resync tftp://192.168.37.251:69/spa000e08cb6317.cfg
SPA-3102 00:0e:08:cb:63:17 -- Resync failed: corrupt file

[SARK devs]

It's does not look right.

Here's our test spannnn.cfg file....

Code: [Select]

<flat-profile>
<Proxy_1_> 192.168.1.210
</Proxy_1_>
<Outbound_Proxy_1_> 192.168.1.210
</Outbound_Proxy_1_>
<User_ID_1_> 4006
</User_ID_1_>
<Password_1_> 4006
</Password_1_>
<Display_Name_1_> freddyK
</Display_Name_1_>
<Dial_Plan_1_> (*x.|*xx*x.|x.)
</Dial_Plan_1_>
<Time_Zone> GMT
</Time_Zone>
<Resync_Periodic> 3600
</Resync_Periodic>
</flat-profile>
<Proxy_2_> 192.198.1.210
</Proxy_2_>
<Outbound_Proxy_2_> 192.168.1.210
</Outbound_Proxy_2_>
<User_ID_2_> 514414
</User_ID_2_>
<Password_2_> asterisk
</Password_2_>
<Display_Name_2_> 514414
</Display_Name_2_>
<Dial_Plan_2_2_> (S0&lt;:514414&gt;)
</Dial_Plan_2_2_>
<FAX_Passthru_Method_2_> None
</FAX_Passthru_Method_2_>
<Line_1_VoIP_Caller_DP_2_> none
</Line_1_VoIP_Caller_DP_2_>
<VoIP_Caller_1_DP_2_> 2
</VoIP_Caller_1_DP_2_>
<PSTN_Ring_Thru_Line_1_2_> no
</PSTN_Ring_Thru_Line_1_2_>
<PSTN_CID_For_VoIP_CID_2_> yes
</PSTN_CID_For_VoIP_CID_2_>
<PSTN_Caller_Default_DP_2_> 2
</PSTN_Caller_Default_DP_2_>
<PSTN_Caller_1_DP_2_> 2
</PSTN_Caller_1_DP_2_>
<PSTN_Answer_Delay_2_> 2
</PSTN_Answer_Delay_2_>
<Min_CPC_Duration_2_> 0.09
</Min_CPC_Duration_2_>
<FXO_Port_Impedance_2_> Global
</FXO_Port_Impedance_2_>
<SPA_To_PSTN_Gain_2_> 3
</SPA_To_PSTN_Gain_2_>
<PSTN_To_SPA_Gain_2_> 5
</PSTN_To_SPA_Gain_2_>
<On-Hook_Speed_2_> 3 ms (ETSI)
</On-Hook_Speed_2_>
<Ring1_Cadence> 60(.4/.2,.4/2)
</Ring1_Cadence>
<Ring2_Cadence> 60(1/2)
</Ring2_Cadence>
<Ring3_Cadence> 60(.25/.25,.25/.25,.25/1.75)
</Ring3_Cadence>
<Ring4_Cadence> 60(.4/.8)
</Ring4_Cadence>
<Ring5_Cadence> 60(2/4)
</Ring5_Cadence>
<FXS_Port_Input_Gain> 0
</FXS_Port_Input_Gain>
<Caller_ID_Method> ETSI FSK With PR(UK)
</Caller_ID_Method>
<FXS_Port_Impedance> 370+620||310nF
</FXS_Port_Impedance>
<FXS_Port_Output_Gain> 7
</FXS_Port_Output_Gain>
<Time_Zone> GMT
</Time_Zone>

Whish release of SAIL are you running?

Best

S

[groutley]

G'day S,
  I am running SAIL Version: 2.1.14-526
Looks like yours does not have an extra line between each ,
but your </flat-profile> is in the middle of the config i.e at the end of the 'line' section,
which is what I assumed must be the problem..
Hmmm
my  spannnnline  and spannnnpstnline  files do not have the extra <CR> between each line.
So the merge of the 2 adds them in ?

G

[SARK devs]

yup - it looks like a bug to me.

I'll take a look at why it's glitching.  The 3000/3102 provisioning is a bit tricksey due to the merge (which you've already worked out).

Thanks for the heads up.

Best

S

[groutley]

Hi S,
 I discovered why I was getting the "Resync failed: corrupt file"
and all my fault !!
I had added a daylight saving rule

Code: [Select]

<Daylight Saving Time Rule> start=3/-1/7/3;end=10/-1/7/2;save=-1

</Daylight Saving Time Rule>
Yes I am sure you spot my error immediately   I did not replace the spaces with '_'
So it seems the extra <CR> are not a problem, might be curious, but they do not cause an issue.
Correcting my Daylight saving statement now  works correctly..

Code: [Select]

System started: ip@192.168.37.250, reboot reason:H30300010
YM:ERR:AuthServerNotConfig
YM:ERR:AuthServerNotConfig
[0]Reg Addr Change(0) 0:0->c0a825fb:5060
[1]Reg Addr Change(0) 0:0->c0a825fb:5060
SPA-3102 00:0e:08:cb:63:17 -- Requesting resync tftp://192.168.37.251:69/spa000e08cb6317.cfg
SPA-3102 00:0e:08:cb:63:17 -- Successful resync tftp://192.168.37.251:69/spa000e08cb6317.cfg
System started: ip@192.168.37.250, reboot reason:W4
YM:ERR:AuthServerNotConfig
YM:ERR:AuthServerNotConfig
[0]Reg Addr Change(0) 0:0->c0a825fb:5060
[1]Reg Addr Change(0) 0:0->c0a825fb:5060
But if you are looking at the provisioning at all for the SPA 3000/3102 I noticed a couple of things I consider odd, or could be improved.

Firstly For the Trunk definition, I cannot edit the provisioning area manually.
I have to delete the Trunk, modify the SPA-3102 Carrier definition, and then re-Add the Trunk.
A slightly tedious method to make a simple change, and not how I expected this to work.

If I manually alter the provisioning section for the defined Trunk, I save, and then go back in and my changes are no longer there.

The 2nd thing is, the <Display_Name_2_> parameter picks up the trunk "Gateway PSTN number: " that is defined, now That field would seem obvious to be filled out with your PSTN subscriber number.
Now the <Display_Name_2_> field on the SPA-3102 is what is displayed on the phone instead of CID, as we do not pay our PSTN provider extra for CID feature.
So our phone displays our own Phone number on the phone display when someone rings our PSTN line.
This I find a bit odd, with my manual SPA configuration, I set this field to 'Telstra call' which nicely tells us the phone is ringing due to incoming call from our Telco provider.
(this makes more sense to the Wife )
Unfortunately I do not appear to be able to Alter this parameter, as whatever magic you have worked, is picking up the PSTN number, and is not even a variable. If it was a variable, I gather I could replace the Variable with my manually entered text.
This Carrier definition seems to work differenty to the IP Device definition where the use of $desc, $ext or $localip could easily be replaced with text.

Lastly, I am getting odd behavior with the Daylight savings rule, I added.
The definition I believe is correct,  but when the spa is automagically provisioned, the time on the SPA is completely wrong ! (well OK the minutes are correct) but it is 11hours slow !
this is curious as I set

Code: [Select]

<Time_Zone> GMT+11:00
</Time_Zone>Now this is where is becomes ODD !!
If I now go to the SPA web interface, make no changes,
but click 'Submit All Changes' from the admin/voice/advanced page, the time beomes correct.
Note from the admin/basic display the clock does not correct itself  !

From previous playing with SPA monitor / logging utilities, I note that the SPA-3102 has specific needs, when compared to a spa-3000, to  be managed correctly, perhaps the SAIL provisioning is not working with the 'advanced' access ?

[SARK devs]

Hi G

I've had a look at the trunk-side of the code this afternoon (sad bugger that I am... working on a Sunday) and there's a hole in there big enough to drive a bus through....  Heads will roll in the morning.

It's in a fairly tricksie area but I'll get a patch done as soon as we can find a work slot for it.

Thanks for all of your help.

Kind Regards

S

[SARK devs]

HI G

We've just released an update with fixes for the spa3xxx issues you reported.  Unfortunately, owing to the fact that we don't have a lot of spare development time, the fixes have been done in the 2.2.1 branch ONLY.  2.2.1-538 is available for download from the ftp site and it has been tested with an SPA-3000 and an SPA-2102 ('cos that's all we had lying around).  I think we've fixed the majority of the issues you uncovered but we'd like you to gve it a run 'round the block if you have the time.  I can confirm (because I tested some of the functions myself) that you can now modify the generated entries in Trunks and your changes will persist across commits.  You can also freely modify the 3102 template if you feel it needs work.  We've never tested on a 3102 for the simple reason that we don't have one.  By default, we still generate spa-3000/3102 entries with their own phone number in the CLI/TAG field, however you can change this to whatever you wish.  The current templates (in devices and carriers) generate UK impedances and termination detection timings and you should change these for your own local Telco's settings BEFORE you create any trunks or extensions.

PAP2's will NOT autoprovision with this release.  I'm going to call the distributor tomorrow to see if we can get hold of a PAP2 for testing purposes.

Thanks again for your help

S


 

[groutley]

Hi Jeff,
  Thanks for that update.  (I think)
Wasn't sure whether to make the plunge into the beta 2.2 stuff, but I guess you talked me into it.

The good news is the SPA provisioning is looking good, the bad news is I can't receive or make any phone calls !
I think the main concern is 'Unable to open Asterisk database' messages..

Code: [Select]

  == Auto fallthrough, channel 'SIP/5010-094a35a8' status is 'UNKNOWN'
    -- Executing [h@internal:1] Hangup("SIP/5010-094a35a8", "") in new stack
  == Spawn extension (internal, h, 1) exited non-zero on 'SIP/5010-094a35a8'
[Oct 30 16:22:55] NOTICE[8123]: cdr.c:434 ast_cdr_free: CDR on channel 'SIP/5010-094a35a8' not posted
[Oct 30 16:23:07] NOTICE[4564]: chan_sip.c:14776 handle_request_subscribe: Got SUBSCRIBE for extension 5001@internal from 192.168.37.19, but there is no hint for that extension.
    -- Executing [5010@internal:1] AGI("SIP/5000-094b6848", "selintra|OutCluster|5010") in new stack
    -- Launched AGI Script /var/lib/asterisk/agi-bin/selintra
    -- AGI Script selintra completed, returning 0
  == Auto fallthrough, channel 'SIP/5000-094b6848' status is 'UNKNOWN'
    -- Executing [h@internal:1] Hangup("SIP/5000-094b6848", "") in new stack
  == Spawn extension (internal, h, 1) exited non-zero on 'SIP/5000-094b6848'
[Oct 30 16:23:13] NOTICE[8127]: cdr.c:434 ast_cdr_free: CDR on channel 'SIP/5000-094b6848' not posted
[Oct 30 16:24:04] WARNING[4564]: db.c:66 dbinit: Unable to open Asterisk database
[Oct 30 16:24:04] WARNING[4564]: db.c:66 dbinit: Unable to open Asterisk database
those Warning message just keep scrolling..

I can dial *56* from an extension and get told the xtn # correctly.
I cannot dial another extension, I cant dial out any Trunk, or recieve any incoming calls !!

I followed the Instructions on  http://www.selintra.com/docs/cgi-bin/view/Main/DocChapter03b
i.e. rpm -e selintra-sail
rpm -e smeserver-asterisk
rpm -e smeserver-asterisk-zappri-MPP

then after midifying my yum.conf ..
yum install zaptel --enablerepo=atrpms
yum install libpri  --enablerepo=atrpms
yum install asterisk --enablerepo=atrpms
yum install zaptel-kmdl-`uname -r` --enablerepo=atrpms
yum install asterisk-addons  --enablerepo=atrpms
then downloaded the sail-2.2.1-538.noarch.rpm and performed
yum localinstall sail-2.2.1-538.noarch.rpm --enablerepo=base

finally with the signal-event post-upgrade; signal-event reboot

Then I did a commit, from the Globals page, followed by a 'Probe' on the PCI devices, and another commit.

HELP   

[SARK devs]

HI

sounds something is getting left behind after the uninstall. 

what do you have in musiconhold.conf?
what does ls -l /var/lib/asterisk/agi-bin show?

Stop asterisk from the console with "stop now"
Start it with asterisk -vvvvc

at the console do "agi debug"

run an internal call and post the console log


Best

S

[groutley]

Thanks Jeff,

musiconhold.conf

Code: [Select]

[root@l1nuxsvr asterisk]# cat musiconhold.conf
;#------------------------------------------------------------
;# DO NOT MODIFY THIS FILE! It is updated automatically by the
;# SME Server software. Instead, modify the source template in
;# an /etc/e-smith/templates-custom directory. For more
;# information, see http://www.e-smith.org/custom/
;#
;# copyright (C) 2005 Selintra Ltd. United Kingdom
;#------------------------------------------------------------

[default]
mode=files
directory=>/var/lib/asterisk/moh
random=yes

ls -l /var/lib/asterisk/agi-bin

Code: [Select]

[root@l1nuxsvr asterisk]# ls -l /var/lib/asterisk/agi-bin
total 104
-rwxr-xr-x  1 asterisk asterisk  1742 Oct 10 15:12 agi-test.agi
-rwxr-xr-x  1 asterisk asterisk  7216 Oct 10 15:13 eagi-sphinx-test
-rwxr-xr-x  1 asterisk asterisk  6120 Oct 10 15:13 eagi-test
-rwxr-xr-x  1 asterisk asterisk 14530 Oct 10 15:12 jukebox.agi
-rwxr-xr-x  1 root     root     62200 Oct 30 10:04 selintra

Connected to Asterisk 1.4.12.1 currently running on l1nuxsvr (pid = 4425)
Verbosity is at least 7
l1nuxsvr*CLI> stop now
l1nuxsvr*CLI>
Disconnected from Asterisk server
[root@l1nuxsvr asterisk]#asterisk -vvvvc

Code: [Select]

AGI Debugging Enabled
*CLI>     -- Executing [5010@internal:1] AGI("SIP/5009-0a126180", "selintra|OutCluster|5010") in new stack
    -- Launched AGI Script /var/lib/asterisk/agi-bin/selintra
AGI Tx >> agi_request: selintra
AGI Tx >> agi_channel: SIP/5009-0a126180
AGI Tx >> agi_language: en
AGI Tx >> agi_type: SIP
AGI Tx >> agi_uniqueid: 1193742185.0
AGI Tx >> agi_callerid: 5009
AGI Tx >> agi_calleridname: Glen
AGI Tx >> agi_callingpres: 0
AGI Tx >> agi_callingani2: 0
AGI Tx >> agi_callington: 0
AGI Tx >> agi_callingtns: 0
AGI Tx >> agi_dnid: 5010
AGI Tx >> agi_rdnis: unknown
AGI Tx >> agi_context: internal
AGI Tx >> agi_extension: 5010
AGI Tx >> agi_priority: 1
AGI Tx >> agi_enhanced: 0.0
AGI Tx >> agi_accountcode:
AGI Tx >>
AGI Rx << SET PRIORITY 1
AGI Tx >> 200 result=0
AGI Rx << SET EXTENSION 5010
AGI Tx >> 200 result=0
AGI Rx << SET CONTEXT Home
AGI Tx >> 200 result=0
    -- AGI Script selintra completed, returning 0
    -- Executing [5010@Home:1] AGI("SIP/5009-0a126180", "selintra|InCall|") in new stack
    -- Launched AGI Script /var/lib/asterisk/agi-bin/selintra
AGI Tx >> agi_request: selintra
AGI Tx >> agi_channel: SIP/5009-0a126180
AGI Tx >> agi_language: en
AGI Tx >> agi_type: SIP
AGI Tx >> agi_uniqueid: 1193742185.0
AGI Tx >> agi_callerid: 5009
AGI Tx >> agi_calleridname: Glen
AGI Tx >> agi_callingpres: 0
AGI Tx >> agi_callingani2: 0
AGI Tx >> agi_callington: 0
AGI Tx >> agi_callingtns: 0
AGI Tx >> agi_dnid: 5010
AGI Tx >> agi_rdnis: unknown
AGI Tx >> agi_context: Home
AGI Tx >> agi_extension: 5010
AGI Tx >> agi_priority: 1
AGI Tx >> agi_enhanced: 0.0
AGI Tx >> agi_accountcode:
AGI Tx >>
AGI Rx << DATABASE GET "STAT" "OCSTAT"
AGI Tx >> 200 result=0
AGI Rx << DATABASE GET "cfimopen" "5010"
AGI Tx >> 200 result=0
AGI Rx << DATABASE GET "cfim" "5010"
AGI Tx >> 200 result=0
AGI Rx << DATABASE GET "STAT" "OCSTAT"
AGI Tx >> 200 result=0
AGI Rx << DATABASE GET "cfimopen" "5010"
AGI Tx >> 200 result=0
AGI Rx << DATABASE GET "STAT" "OCSTAT"
AGI Tx >> 200 result=0
AGI Rx << DATABASE GET "cfim" "5010"
AGI Tx >> 200 result=0
AGI Rx << DATABASE GET "ringdelay" "5010"
AGI Tx >> 200 result=0
AGI Rx << GET VARIABLE MOH
AGI Tx >> 200 result=0
AGI Rx << EXEC Dial SIP/5010|20|tTwW
    -- AGI Script Executing Application: (Dial) Options: (SIP/5010|20|tTwW)
    -- Called 5010
    -- SIP/5010-0a12b3f8 is ringing
[Oct 30 22:03:06] NOTICE[10112]: cdr.c:434 ast_cdr_free: CDR on channel 'SIP/5010-0a12b3f8' not posted
AGI Tx >> 200 result=-1
  == Spawn extension (Home, 5010, 1) exited non-zero on 'SIP/5009-0a126180'
    -- Executing [h@Home:1] Hangup("SIP/5009-0a126180", "") in new stack
  == Spawn extension (Home, h, 1) exited non-zero on 'SIP/5009-0a126180'

Hmm  it worked !
Very odd,  I have been out at my sons school presentation night,
the last thing I did before leaving was another "signal-event post-upgrade; signal-event reboot"

Seems that all is good again after that !..
I have not fully tested, as it is late and with phones ringing all around the house I won't be popular,
But I am happy for now.. 
Really appreciate your speedy diagnostic reply, but panic is off for now 

I'll play more tomorrow if I get a chance, although I may have to travel interstate with work yet.
Thanks again 
 G

[SARK devs]

Good oh.

No hurry, but we're looking forward to your verdict on our spa provisioning efforts.

Kind Regards

S

[groutley]

Hi Jeff,
  OK spoke too soon,
it gets wierder !
I did a 'signal-event reboot'  to cleanly restart and have sail brought up normaly.
and it doesn't work again !
Same issue,  cant ring extensions..  cant recieve incoming calls. etc..

So I stop asterisk again, and start with 'asterisk -vvvvc
and All works !!
I restart 'signal-event reboot' again, and Yes  It's broken again !!
When I call another extn

Code: [Select]

    -- Executing [10@internal:1] AGI("SIP/5009-096da858", "selintra|OutCluster|10") in new stack
    -- Launched AGI Script /var/lib/asterisk/agi-bin/selintra
    -- AGI Script selintra completed, returning 0
  == Auto fallthrough, channel 'SIP/5009-096da858' status is 'UNKNOWN'
    -- Executing [h@internal:1] Hangup("SIP/5009-096da858", "") in new stack
  == Spawn extension (internal, h, 1) exited non-zero on 'SIP/5009-096da858'
[Oct 30 22:43:42] NOTICE[5215]: cdr.c:434 ast_cdr_free: CDR on channel 'SIP/5009-096da858' not posted

with an incoming PSTN call via the SPA-3102 trunk

Code: [Select]

    -- Executing [97951738@mainmenu:1] AGI("SIP/97951738-096da858", "selintra|Inbound|97951738") in new stack
    -- Launched AGI Script /var/lib/asterisk/agi-bin/selintra
    -- AGI Script selintra completed, returning 0
  == Auto fallthrough, channel 'SIP/97951738-096da858' status is 'UNKNOWN'
    -- Executing [h@mainmenu:1] Hangup("SIP/97951738-096da858", "") in new stack
  == Spawn extension (mainmenu, h, 1) exited non-zero on 'SIP/97951738-096da858'
[Oct 30 22:44:14] NOTICE[5219]: cdr.c:434 ast_cdr_free: CDR on channel 'SIP/97951738-096da858' not posted

I am also in this state still getting...

Code: [Select]

[Oct 30 22:45:00] WARNING[4120]: db.c:66 dbinit: Unable to open Asterisk database
[Oct 30 22:45:24] WARNING[4120]: db.c:66 dbinit: Unable to open Asterisk database
[Oct 30 22:45:25] WARNING[4120]: db.c:66 dbinit: Unable to open Asterisk database
[Oct 30 22:45:25] WARNING[4120]: db.c:66 dbinit: Unable to open Asterisk database
[Oct 30 22:46:06] WARNING[4120]: db.c:66 dbinit: Unable to open Asterisk database
[Oct 30 22:47:55] WARNING[4120]: db.c:66 dbinit: Unable to open Asterisk database
[Oct 30 22:48:19] WARNING[4120]: db.c:66 dbinit: Unable to open Asterisk database
[Oct 30 22:48:22] WARNING[4120]: db.c:66 dbinit: Unable to open Asterisk database
[Oct 30 22:48:22] WARNING[4120]: db.c:66 dbinit: Unable to open Asterisk database
[Oct 30 22:48:24] NOTICE[4120]: chan_sip.c:14776 handle_request_subscribe: Got SUBSCRIBE for extension 5001@internal from 192.168.37.19, but there is no hint for that extension.
[Oct 30 22:48:49] WARNING[4120]: db.c:66 dbinit: Unable to open Asterisk database

Any ideas ?
at least I have a work around

G

[groutley]

Update..
  if I 'stop now' asterisk
and then  ' /etc/init.d/sark start '
All works !

So is there a left over that is kicking off the previous version during SME boot ?

[groutley]

No hurry, but we're looking forward to your verdict on our spa provisioning efforts.

OK, I have played a bit now with the SPA-3102 provisioning,
while mucking around with the above wierd symptoms.

I Australianized the spa-3102fxo and fxs templates,
deleted and re-added both my SPA3102 extn and Trunk.
I am now able to put 'telstra call' into the PSTN Display name
and edit the current trunk provisioning
all the extra <CR> in the spa____.cfg have gone
even the <flat-profile>, </flat-profile>  appear only at the begining and end of the cfg
Wow what a great clean up !  looking really good.

Only one extra that I hadn't previously mentioned.
on the spa-3102 the 'Profile Rule' of /spa$MA.cfg
requests the spa_____.cfg from the tftp server as a Lowercase name.
So while I define each of the trunk and extension,
I type the MAC address of the SPA3102 with lower case alpha characters,
But when I go into the trunk or extension definition, the MAC has become uppercase,
so of course the SPA will not find the cfg file.
I can correct the defined trunk and extension so the MAC is lower case, and all works great.
but if I enter the MAC in lower case, it should not translate to upper,
I would expect the behaviour to be a direct entry.
i.e. If I entered lower case alpha characters in the MAC, then it should accept and keep the lower case,
If I type in Upper case, it should keep and Use the Uppercase characters as I entered.

If it worked like that I can't whinge, about SAIL transposing my characters,  I could only blame myself for poor typing

Otherwise I really think the 3102 provisioning is looking great !

G

[SARK devs]

Excellent....

re profile rule...

/spa$MA.cfg will cause the 3102 look for a lower case name file, /spa$MAU.cfg will cause it to look for uppercase.  You should be abe to set this in the spa3102.cfg descriptor so that it is picked up during two-phase cold boot or you can set it via the browser or just take whatever the unit defaults to (usually $MA).

In our keywords (at the beginning of the provisioning stream), "spa$MAC.cfg" will produce a tftp file with uppercase mac address and "spa$mac.cfg" will produce a tftp file with lowercase mac address.

So you have full control to change what the unit is looking for and what file name we will set.


For your problem at start up do...

config setprop asterisk status disabled

That should do it.

We'll fix this properly in a very near release.

Kind Regards

S

[SARK devs]

-540 should cure your strange start-up behaviour ills.

It's up on the ftp site now.

Kind Regards

S

[groutley]

Hi Jeff,
 I have installed -540 and appears to have corrected my statup blues  thanks ,
But I am now seeing some odd stuff in the Sark FOP.
No longer are my Trunks listed at all,
But there are some odd ones..
Telappliant1
astratel1
switchtiny
test65tiny

Also extns 5000 thru 5004 display, yet I dont have xtns 5001thru 5003 and my other extensions I do have are not displayed at all ?
I have a feeling something got broken in the SARK FOP build code, and a test config remains.
It is Beta code after all 
Glen

[SARK devs]

almost certainly broken.

I'll put it on the list.

Might get a fix out mon/tues.

Best and thanks

J

[SARK devs]

This is odd.  You are picking up the test data from the FOP .cfg file in the distribution.  It's almost as if you've never done a commit since you installed the new package.

Hmmm.

Do a commit and have a look in the logs for me (just the regular SME messages log)...

What you are looking for is this...(this is our reference 2.1.1/1.4 system)

Code: [Select]

Nov  2 15:27:13 switch esmith::event[16637]: Processing event: conf-fop 
Nov  2 15:27:13 switch esmith::event[16637]: Running event handler: /etc/e-smith/events/actions/generic_template_expand
Nov  2 15:27:14 switch esmith::event[16637]: expanding /usr/local/operator/op_buttons.cfg 
Nov  2 15:27:14 switch esmith::event[16637]: expanding /usr/local/operator/op_server.cfg 
Nov  2 15:27:15 switch esmith::event[16637]: generic_template_expand=action|Event|conf-fop|Action|generic_template_expand|Start|1194017233 912607|End|1194017235 74048|Elapsed|1.161441
Nov  2 15:27:15 switch esmith::event[16637]: Running event handler: /etc/e-smith/events/conf-fop/S55conf-fop
Nov  2 15:27:16 switch fop: op_server.pl shutdown succeeded
Nov  2 15:27:16 switch esmith::event[16637]: Shutting down Flash Operator Panel: [  OK  ]
 
Nov  2 15:27:17 switch fop: op_server.pl startup succeeded
Nov  2 15:27:17 switch esmith::event[16637]: Starting Flash Operator Panel: [  OK  ]

See if you are getting any failures in this sequence

Best

S

[groutley]

Hi Jeff,
  curious, about to do a commit, (which possibly was an oversight on my part),
I go into Global Settings and at the top of the panel its says
"Version: sail-2.2.1-538 sail-2.2.1-540 " 

So now I do the commit..

Code: [Select]

Nov  3 08:26:08 l1nuxsvr esmith::event[2788]: Processing event: conf-fop
Nov  3 08:26:08 l1nuxsvr esmith::event[2788]: Running event handler: /etc/e-smith/events/actions/generic_template_expand
Nov  3 08:26:09 l1nuxsvr esmith::event[2788]: expanding /usr/local/operator/op_server.cfg
Nov  3 08:26:09 l1nuxsvr esmith::event[2788]: expanding /usr/local/operator/op_buttons.cfg
Nov  3 08:26:09 l1nuxsvr esmith::event[2788]: generic_template_expand=action|Event|conf-fop|Action|generic_template_expand|Start|1194038768 760037|End|1194038769 672080|Elapsed|0.912043
Nov  3 08:26:09 l1nuxsvr esmith::event[2788]: Running event handler: /etc/e-smith/events/conf-fop/S55conf-fop
Nov  3 08:26:09 l1nuxsvr fop: op_server.pl shutdown succeeded
  v  3 08:26:10 l1nuxsvr esmith::event[2788]: Shutting down Flash Operator Panel: [  OK  ]
Nov  3 08:26:10 l1nuxsvr fop: op_server.pl startup succeeded
  v  3 08:26:10 l1nuxsvr esmith::event[2788]: Starting Flash Operator Panel: [  OK  ]
Nov  3 08:26:10 l1nuxsvr esmith::event[2788]: S55conf-fop=action|Event|conf-fop|Action|S55conf-fop|Start|1194038769 672911|End|1194038770 832668|Elapsed|1.159757
Nov  3 08:26:10 l1nuxsvr esmith::event[2762]: S55conf-asterisk=action|Event|conf-asterisk|Action|S55conf-asterisk|Start|1194038767 929653|End|1194038770 845070|Elapsed|2.915417
Nov  3 08:26:10 l1nuxsvr /etc/e-smith/web/panels/manager/cgi-bin/sarkglobals[2524]: /home/e-smith/db/selintra-work: OLD global=globals|ADDHEADER|NO|AGENTSTART|1001|ALERT|None|CALLRECORD1|One-Touch|CALLRECORD2|None|CDR|YES|CFEXTRN|ON|COMMIT|NO|COMPRESSION|THRUPUT|CONFTYPE|simple|COUNTRY|au|DIGITS|2|DIGIUMCARD|NO|DISAPASSWORD||EDOMAIN||EMAILALERT|glen@routley.homeip.net|FAX|5003|FAXDETECT|3|FOPPASS|1234|FORMAT-2.1.11|YES|G729||INTRINGDELAY|20|LCLVOIPMAX|10|LOCALIP|192.168.37.251|LOGBAK||LOGOPTS|native|LTERM|NO|MAILMODE|automatic|MEETMEDIAL|_30[0-7]|ONETOUCHREC|NO|OPERATOR|0|PLAYBEEP|NO|PLAYBUSY|NO|PLAYCONGESTED|NO|PROXY|NO|PROXYIGNORE||RINGDELAY|0|SIPIAXSTART|5000|SMSALERT||SMSC||SPYPASS|4444|SUBNET|192.168.37.0|SUPEMAIL|admin@routley.homeip.net|SYSOP|5010|SYSPASS|1111|TFTP|YES|TIMEOUTD|5|TIMEOUTR|10|UNDO|YES|UNDONUM|3|VLIBS|/var/log /var/lib/mysql /var/lib/dhcp /var/lock /var/qmail /var/spool /var/tmp /tmp /tftpboot|VMAILSERVER||VOICEINSTR|YES|VOIPMAX|3
Nov  3 08:26:10 l1nuxsvr /etc/e-smith/web/panels/manager/cgi-bin/sarkglobals[2524]: /home/e-smith/db/selintra-work: NEW global=globals|ADDHEADER|NO|AGENTSTART|1001|ALERT|None|CALLRECORD1|One-Touch|CALLRECORD2|None|CDR|YES|CFEXTRN|ON|COMMIT|NO|COMPRESSION|THRUPUT|CONFTYPE|simple|COUNTRY|au|DIGITS|2|DIGIUMCARD|NO|DISAPASSWORD||EDOMAIN||EMAILALERT|glen@routley.homeip.net|FAX|5003|FAXDETECT|3|FOPPASS|1234|FORMAT-2.1.11|YES|G729||INTRINGDELAY|20|LCLVOIPMAX|10|LOCALIP|192.168.37.251|LOGBAK||LOGOPTS|native|LTERM|NO|MAILMODE|automatic|MEETMEDIAL|_30[0-7]|ONETOUCHREC|NO|OPERATOR|0|PLAYBEEP|NO|PLAYBUSY|NO|PLAYCONGESTED|NO|PROXY|NO|PROXYIGNORE||RINGDELAY|0|SIPIAXSTART|5000|SMSALERT||SMSC||SPYPASS|4444|SUBNET|192.168.37.0|SUPEMAIL|admin@routley.homeip.net|SYSOP|5010|SYSPASS|1111|TFTP|YES|TIMEOUTD|5|TIMEOUTR|10|UNDO|YES|UNDONUM|4|VLIBS|/var/log /var/lib/mysql /var/lib/dhcp /var/lock /var/qmail /var/spool /var/tmp /tmp /tftpboot|VMAILSERVER||VOICEINSTR|YES|VOIPMAX|3


Global Panel says..  "Operation status report -  Globals saved"
and still at the top "Version: sail-2.2.1-538 sail-2.2.1-540"
But hey,  my SARK fop panel is back to normal.
So I guess I have been a very naughty boy !  although the Version display does seem odd.

Now I am curious, in the test.cfg display I saw, obviously it was slightly customised.
My Trunks just display 'Trunk 1', 'Trunk 2' etc.. 
Can I customise these to actually disply the trunk name ?
Also When I look at the SARK web site it displays a VERY different looking FOP,
is this a SARK upgrade required, or is that achievable in a conf file ?

[SARK devs]

SARK FOP trunks use a cute self-defining technique which means they act like a pool and will reflect incoming SIP and IAX calls as they arrive.  Most (all?) other implementations  we've seen use a fixed number of trunks for each channel type (ZAP, SIP, IAX).  This is quite inflexible and you have to guess in advance how many of each are required.

Can you change it?  Weeell, possibly.  SARK synthesises the layout using SME templates.  Best we could do is to give you a switch to turn off SARK processing altogether and then you can do whatever you wish.  The buttons.cfg file which FOP uses isn't difficult to hand build. You can view SARK's efforts at /usr/local/operator/op_buttons.cfg.

Might not be a bad idea, we can put it on the build list.

As to your strange output for the version.  Never seen that happen before.  We don't keep the version anywhere in SARK itself, we simply query rpm with "rpm -q sail" and then print the output.  Never seen rpm -q give two versions.  What's that all about?



Best

S

 

[groutley]

Hi Jeff,
 your explanation on the fop makes sense to me,  I had been looking at the 0.27 release of fop and the demo panels, and liked the look,  but your trunk implementation certainly makes sense, and I would be silly to change that clever implementation.
Anyway,  I seem to be having another problem, 
I have a couple of different VSP's each with different DID's,
currently when ringing the DID, it gets to SAIL/Asterisk,  but never rings an extension
here is an agi debug of an incoming call..

Code: [Select]

    -- Executing [s@mainmenu:1] AGI("SIP/61386835551-09fefcb0", "selintra|CheckState|") in new stack
    -- Launched AGI Script /var/lib/asterisk/agi-bin/selintra
AGI Tx >> agi_request: selintra
AGI Tx >> agi_channel: SIP/61386835551-09fefcb0
AGI Tx >> agi_language: en
AGI Tx >> agi_type: SIP
AGI Tx >> agi_uniqueid: 1194260114.0
AGI Tx >> agi_callerid: 0396270000
AGI Tx >> agi_calleridname: unknown
AGI Tx >> agi_callingpres: 0
AGI Tx >> agi_callingani2: 0
AGI Tx >> agi_callington: 0
AGI Tx >> agi_callingtns: 0
AGI Tx >> agi_dnid: unknown
AGI Tx >> agi_rdnis: unknown
AGI Tx >> agi_context: mainmenu
AGI Tx >> agi_extension: s
AGI Tx >> agi_priority: 1
AGI Tx >> agi_enhanced: 0.0
AGI Tx >> agi_accountcode:
AGI Tx >>
AGI Rx << DATABASE GET "STAT" "OCSTAT"
AGI Tx >> 200 result=0
AGI Rx << SET VARIABLE REMOTENUM ""
AGI Tx >> 200 result=1
AGI Rx << SET VARIABLE OPEN "YES"
AGI Tx >> 200 result=1
AGI Rx << DATABASE GET "STAT" "IVRSTAT"
AGI Tx >> 200 result=0
AGI Rx << SET PRIORITY 1
AGI Tx >> 200 result=0
AGI Rx << SET EXTENSION
AGI Tx >> 520-Invalid command syntax.  Proper usage follows:
AGI Tx >>  Usage: SET EXTENSION <new extension>
        Changes the extension for continuation upon exiting the application.
AGI Tx >> 520 End of proper usage.
AGI Rx << SET CONTEXT extensions
AGI Tx >> 200 result=0
    -- AGI Script selintra completed, returning 0
    -- Sent into invalid extension 's' in context 'extensions' on SIP/61386835551-09fefcb0
    -- Executing [i@extensions:1] PlayTones("SIP/61386835551-09fefcb0", "congestion") in new stack
  == Auto fallthrough, channel 'SIP/61386835551-09fefcb0' status is 'UNKNOWN'
    -- Executing [h@extensions:1] Hangup("SIP/61386835551-09fefcb0", "") in new stack
  == Spawn extension (extensions, h, 1) exited non-zero on 'SIP/61386835551-09fefcb0'
[Nov  5 21:55:14] NOTICE[16239]: cdr.c:434 ast_cdr_free: CDR on channel 'SIP/61386835551-09fefcb0' not posted

Eventually I get a reorder tone on the phone I dialled from, as the call never connects, not even to voicemail.
Like I said this is ocurring with 2 different VSP's and I have tried changing the Inbound Route to various extensions with the same result.
All extensions and dial out thru these Trunks works fine.

G

[groutley]

As to your strange output for the version.  Never seen that happen before.  We don't keep the version anywhere in SARK itself, we simply query rpm with "rpm -q sail" and then print the output.  Never seen rpm -q give two versions.  What's that all about?

I really don't know,  but you are correct (yet again) if I rpm -q sail
it lists both versions of sail.

So I have now done an rpm -e sail-2.2.1-538
just to be safe I also did a rpm -e sail-2.2.1-540
and then a yum localinstall sail-2.2.1-540...

This appears to have worked OK, and I now only have one version of sail installed.
hopefully this was the correct method to correct the situation.

G

[SARK devs]

They're all correct if they work 

Best

S

[groutley]

Anyway,  I seem to be having another problem, 
I have a couple of different VSP's each with different DID's,

Hi Jeff,
  did you miss this one ?
I still have the problem and deleting / redefining the trunk makes no difference.
Does the AGI trace give a clue ?

[SARK devs]

Sorry -  missed this.

I can tell you what is happening but perhaps not why.  Your trace is calling AGI(CheckState) from the generated extensions.conf.  This narrows it down a bit since CheckState is only ever called once directly from extensions.  Essentially, a call has arrived with no DNID set.  In theory, this should only ever happen on a regular pots line.  Here's what normally happens on a regular SIP call

Code: [Select]

Executing [84411483@mainmenu:1] AGI("SIP/84411483-b7ea1168", "selintra|Inbound|84411483")
Notice two things; (1) we have a DNID (84411483@mainmenu) and this causes AGI(Inbound) to be called to handle it.

Now... Look at yours

Code: [Select]

Executing [s@mainmenu:1] AGI("SIP/61386835551-09fefcb0", "selintra|CheckState|")
No DNID, so the "s" extension gets driven (s@mainmenu).  This causes SARK to assume that this is some kind of ZAP call (which it isn't).  It processes through the ZAP channels looking for the call and doesn't find it.  It now calls checkstate in the hope that it will get resolved in the AGI (it doesn't). so it gives up and generates a congestion tone.

So...  Check that you have a valid "operator" extension set in globals and look at where you are attempting to send the calls (in their Trunk entries).

Next, run a sip trace to see what the carrier is actually handing you in the invite because something is not quite right here.

Kind Regards

S

[groutley]

Hi Jeff,
  curious..
It seems that the 'Operator' extension was lost during the recent upgrades,  so defining this, does at least cause the call to go thru to the 'operator'.

Code: [Select]

    -- Executing [s@mainmenu:1] AGI("SIP/61386835551-b7e01e30", "selintra|CheckState|") in new stack
    -- Launched AGI Script /var/lib/asterisk/agi-bin/selintra
    -- AGI Script selintra completed, returning 0
    -- Executing [5010@extensions:1] AGI("SIP/61386835551-b7e01e30", "selintra|InCall|") in new stack
    -- Launched AGI Script /var/lib/asterisk/agi-bin/selintra
    -- AGI Script Executing Application: (Dial) Options: (SIP/5010|20|tTwW)
    -- Called 5010
    -- SIP/5010-0a09c960 is ringing

But notice it still executes s@mainmenu:1, so I assume it still believes no DNID set (Destination Number ??)
I am guessing this DNID is the 'Open Inbound Route' set in the Trunk panel ?
and I have this set to extension 5009,  but as you can see the call does not goto 5009 it goes to 5010 (the operator extn).
I am not sure how to run a SIP trace, but given this is occurring from two different VSP's(Pennyteal and MyNetPhone) and these were working fine before my recent upgrading etc, I doubt that there is something odd from the providers going on.
G

[SARK devs]

Hi

OK - now I suspect something really odd.  Let's take this offline.
Drop me an e-mail at admin@selintra.com

I will run through trace procedures and so forth

Thanks for all of your help

S

[gippsweb]

Jeff

Since the upgrade to 2.2.1.*** with the new asterisk startup command asterisk appears to be trying to start twice.
The first time it starts and runs, but is loading before udev runs.
After udev runs it tries to start again, obviously the second time fails. The problem being that even though * has loaded, nothing works unless I go the the pci cards page and staop and start * again, from there everything is fine.

I'm guessing I need to stop the first instance from loading to give udev time to do its thing, but don't know where to find it.

PS Thanks for pointing me to Peter the other day.

[groutley]

gipsweb,
  did you try 'config setprop asterisk status disabled'

that fixed my double starting issue  mentioned back on page 2 of this thread.

[SARK devs]

Code: [Select]

Since the upgrade to 2.2.1.*** with the new asterisk startup command
asterisk appears to be trying to start twice.
Er...  There's a reason for that.  It is trying to start up twice.  My fault, can't blame anyone else 'cos I did the startup daemon.  It's a hatchet job.  Originally there were going to be two daemons; sark and sarkbri.  Then I decided just to have one and regressed svn which left the original asterisk starter (what a prat).  It'll all be fixed this weekend with a bit of luck.  In the meantime just turn the asterisk starter off using groutley's advice above.

Best

S