Topic: [Announce]... Er... Loads of Asterisk/SAIL stuff

[SARK devs]

Hi KB

Thanks for this.  You spotted a bug.  I've just looked back through the asterisk package server history and I found an error in the -8 packaging.

I've put up a -9 version which I would very much like you to test.  I can't load it to ibiblio from here so I've opened up a temporary ftp server for you.  You should be able to get -9 with....

Code: [Select]

wget ftp://selintra.com/anabri-asterisk-florz-1.2.10-9.i686.rpm

Kind regards and thanks

Selintra

[kb-ohnemus]

Hi Selintra,

I can't find the new file on that ftp so far.

Manuel

[SARK devs]

Try now

[kb-ohnemus]

Now it works. I tried deleting the modules in 2.6.9-42.0.10.EL and they are copied there again when asterisk restarts.

Thanks
Manuel

[SARK devs]

Excellent

Thanks for your help KB.  I'll load -9 to ibiblio this morning.

Best

Selintra

[rcasado]

Hello Selintra,

As always, my compliments  
I've run into a small stumbling block and was wondering if I could get your help. Version 2.1.15-468 runs flawlessly on SIP channels but I keep getting a failure when dialing into the ZAP channel:

  == Parsing '/etc/asterisk/asterisk.conf': Found
  == Parsing '/etc/asterisk/extconfig.conf': Found
Connected to Asterisk 1.4.1 currently running on garthog (pid = 4407)
Verbosity is at least 5
    -- Remote UNIX connection
    -- Starting simple switch on 'Zap/1-1'
[Jun  9 09:15:48] NOTICE[4563]: chan_zap.c:6327 ss_thread: Got event 18 (Ring Begin)...
[Jun  9 09:15:48] NOTICE[4563]: chan_zap.c:6327 ss_thread: Got event 2 (Ring/Answered)...
    -- Executing [s@mainmenu:1] GotoIf("Zap/1-1", "1?s-Zap1-1|1") in new stack
    -- Goto (mainmenu,s-Zap1-1,1)
    -- Sent into invalid extension 's-Zap1-1' in context 'mainmenu' on Zap/1-1
    -- Executing [i@mainmenu:1] BackGround("Zap/1-1", "invalid") in new stack
    -- <Zap/1-1> Playing 'invalid' (language 'en')
  == CDR updated on Zap/1-1
    -- Executing [0@mainmenu:1] Goto("Zap/1-1", "5000|1") in new stack
    -- Goto (mainmenu,5000,1)
    -- Executing [5000@mainmenu:1] AGI("Zap/1-1", "selintra|InCall|") in new stack
    -- Launched AGI Script /var/lib/asterisk/agi-bin/selintra
    -- AGI Script Executing Application: (Dial) Options: (SIP/5000|15|tTwW)
    -- Called 5000
    -- SIP/5000-0998fc60 is ringing
    -- Got SIP response 480 "Temporarily Unavailable" back from 192.168.0.100
    -- SIP/5000-0998fc60 is circuit-busy
  == Everyone is busy/congested at this time (1:0/1/0)
    -- AGI Script Executing Application: (Background) Options: (silence/1)
    -- <Zap/1-1> Playing 'silence/1' (language 'en')
    -- AGI Script Executing Application: (Voicemail) Options: (u5000)
    -- <Zap/1-1> Playing 'vm-theperson' (language 'en')
    -- <Zap/1-1> Playing 'digits/5' (language 'en')
    -- <Zap/1-1> Playing 'digits/0' (language 'en')
    -- <Zap/1-1> Playing 'digits/0' (language 'en')
    -- <Zap/1-1> Playing 'digits/0' (language 'en')
    -- <Zap/1-1> Playing 'vm-isunavail' (language 'en')
    -- <Zap/1-1> Playing 'vm-intro' (language 'en')
    -- <Zap/1-1> Playing 'beep' (language 'en')
    -- Recording the message
    -- x=0, open writing:  /var/spool/asterisk/voicemail/default/5000/tmp/Mx9Zg4 format: wav49, 0x9904ff0
    -- User hung up
    -- Recording was 5 seconds long but needs to be at least 8 - abandoning
  == Spawn extension (mainmenu, 5000, 1) exited non-zero on 'Zap/1-1'
    -- Executing [h@mainmenu:1] Hangup("Zap/1-1", "") in new stack
  == Spawn extension (mainmenu, h, 1) exited non-zero on 'Zap/1-1'
    -- Hungup 'Zap/1-1'

As you can see, I get the dreaded "That option is invalid" on inbound ZAP channel calls but ZAP does in fact work. The PBX allows me to dial out normally and when I press "0" during the inbound error message, it will in fact ring the phone and operate normally.

Kernel version is 2.6.9-42.0.10.EL and it's on a completely clean install.

Thank you,
R

[SARK devs]

Hi R

You've got us beat with this one.  It's failing in the oldest part of the SAIL code.  That GoToIF cascade is just about the only surviving code from SAIL V1, so it's pretty well tested code!

Can we see the "mainmenu" context?  You can display it in the general edit panel.

It almost looks as though part of the context has been removed/stomped.

Kind Regards

 
S

[rcasado]

Of course!

/etc/asterisk/extensions.conf

[mainmenu]
      include => extensions

   exten =>
         s-Zap1-1,1,agi(selintra,Inbound,Zap1-1)


   exten => s,1,GotoIf($["${CHANNEL}" = "Zap/1-1"]?s-Zap1-1,1)
   exten => s,2,agi(selintra,CheckState,)
       
    exten => fax,1,GoToIf($["$FAX" = ""]?3:2)     ;no FAX defined - hangup
    exten => fax,2,GoTo(extensions,${FAX},1)
     exten => fax,3,Congestion                        
    exten => fax,4,Hangup            

   exten => t,1,GotoIf($["${OPEN}" = "YES"]?t,4)
   exten => t,2,Voicemail(su${SYSOP})      
   exten => t,3,Hangup
   exten => t,4,Goto(extensions,${SYSOP},1)   
         exten => t,5,Hangup

   exten => h,1,Hangup
   
   exten => i,1,Background(invalid) ;  
   exten => i,2,Hangup

/etc/asterisk/zapata.conf

[channels]
hidecallerid=no
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
relaxdtmf=yes
transfer=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=yes
faxdetect=incoming

context=mainmenu
signalling=fxs_ks
group=2
channel=1

Thank you,
R

[SARK devs]

Hi R,

We have a fix for you.  You will find a -470 release on the SAIL download site...

ftp://81.149.154.14/Pre-Releases/selintra-sail-2.1.15-470.noarch.rpm


This will sort out your incoming ZAPline issue.

Kind Regards

S

[llandry]

Hi all,

I've got the following installed:

[root@master sail]# uname -r
2.6.9-42.0.3.EL
[root@master sail]# rpm -q selintra-sail
selintra-sail-2.1.15-468
[root@master sail]# rpm -q smeserver-asterisk
smeserver-asterisk-1.4.1-7
[root@master sail]# rpm -q smeserver-asterisk-zappri-MPP
smeserver-asterisk-zappri-MPP-1.4.0-5
[root@master sail]#

and a X100P card.  When I try to probe for the card, I get the following:

Loading zaptel...
Loading ztdummy...

Zaptel view of card in /proc/zaptel/1
 Span 1: ZTDUMMY/1 "ZTDUMMY/1 1"
 
 


I'm I missing something?  

Thanks

L2

[rcasado]

Hello L2,

What does modprobe zaptel report? Anything at all, or does it silently load? I found a similar problem with 1.4.0-5.i686 and the ELSmp kernel but not the EL.

Thanks Selintra  

Great! BTW, the update on the FTP site is zero bytes long. Could you send it over to the FTP again? Thank you,

[llandry]

modprobe zaptel happily and quitely  loads...

I've tried with both the EL and ELsmp.... At first I thought it was the smp kernel, but the up generated the same results..

[llandry]

Ooops... I lied.


When running the SMP kernel...

modprobe zaptel

FATAL: Error inserting zaptel (/lib/modules/2.6.9-42.0.3.ELsmp/extra/zaptel.ko):        Invalid module format

and the probe times out on UDEV.

So, to recap..

On the EL kernel, modprobe loads the module, but SAIL doesn't see  the card.

On the SMP kernel, the module doesn't load... From what I've been reading, this seems to indicate that the module was compiled with a different kernel.

I'm new to this, so my interpretations may be wrong.

Anyhoo, If anybody can enlighten me, that would be most apprecieated. I've got SAIL 2.1.15-443 running on another box (VoIP only ) and I'm very happy with it...

Thanks again Selintra.


L2

[ldkeen]

FATAL: Error inserting zaptel (/lib/modules/2.6.9-42.0.3.ELsmp/extra/zaptel.ko):        Invalid module format

Yep, I'm getting the same (except mine was 2.6.9-42.0.10.ELsmp). Couldn't get my TDM400 running with the smp modules. In fact I had to drop back to sail-453 with a UP kernel, smeserver-asterisk-1.4.1-3 and smeserver-asterisk-zappri-MPP-1.4.0-4. I also noticed the -470 release on the ftp site was 0 bytes.
I also noticed this in dmesg if it means anything:

Code: [Select]

zaptel: disagrees about version of symbol struct_module
zaptel: disagrees about version of symbol struct_module
zaptel: disagrees about version of symbol struct_module
zaptel: disagrees about version of symbol struct_module
Lloyd

[SARK devs]

Hi Guys,


We hit the same problem ourselves last night and had to back a system off to 42.0.3.   I think we may have overstretched the "just move the modules" theory. (42.0.3 should be fine tho' so I'm not sure about Llandry's issue).

We'll give it a proper look over the next few days but this is just to confirm that we too have hit problems with .10.  Probably just need a recompile from sources but watch this space.

Best


S