Topic: Help please

[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