Topic: Analog-in takes all calls From-PSTN on 3.1.0-116

[compsos]

Hi S
Sail 3.1.0-116
Asterisk 1.8.4
Dahdi 2.4.1.2-2
TDM 422
The calls coming in on the pstn lines is not switching. Dials straight to operator. Also internal calls to the TDM ext go to the operator.
Any clues on where I might find the fault?

Code: [Select]

agi set debug on
AGI Debugging Enabled
    -- Starting simple switch on 'DAHDI/2-1'
    -- Executing [s@from-pstn:1] Goto("DAHDI/2-1", "Analog-In,1") in new stack
    -- Goto (from-pstn,Analog-In,1)
    -- Executing [Analog-In@from-pstn:1] AGI("DAHDI/2-1", "sarkhpe,Inbound") in new stack
    -- Launched AGI Script /var/lib/asterisk/agi-bin/sarkhpe
<DAHDI/2-1>AGI Tx >> agi_request: sarkhpe
<DAHDI/2-1>AGI Tx >> agi_channel: DAHDI/2-1
<DAHDI/2-1>AGI Tx >> agi_language: en
<DAHDI/2-1>AGI Tx >> agi_type: DAHDI
<DAHDI/2-1>AGI Tx >> agi_uniqueid: 1307087181.7
<DAHDI/2-1>AGI Tx >> agi_version: 1.8.4
<DAHDI/2-1>AGI Tx >> agi_callerid: unknown
<DAHDI/2-1>AGI Tx >> agi_calleridname: unknown
<DAHDI/2-1>AGI Tx >> agi_callingpres: 0
<DAHDI/2-1>AGI Tx >> agi_callingani2: 0
<DAHDI/2-1>AGI Tx >> agi_callington: 0
<DAHDI/2-1>AGI Tx >> agi_callingtns: 0
<DAHDI/2-1>AGI Tx >> agi_dnid: unknown
<DAHDI/2-1>AGI Tx >> agi_rdnis: unknown
<DAHDI/2-1>AGI Tx >> agi_context: from-pstn
<DAHDI/2-1>AGI Tx >> agi_extension: Analog-In
<DAHDI/2-1>AGI Tx >> agi_priority: 1
<DAHDI/2-1>AGI Tx >> agi_enhanced: 0.0
<DAHDI/2-1>AGI Tx >> agi_accountcode:
<DAHDI/2-1>AGI Tx >> agi_threadid: -1224918128
<DAHDI/2-1>AGI Tx >> agi_arg_1: Inbound
<DAHDI/2-1>AGI Tx >>
<DAHDI/2-1>AGI Rx << GET VARIABLE EXTLEN
<DAHDI/2-1>AGI Tx >> 200 result=1 (3)
<DAHDI/2-1>AGI Rx << GET VARIABLE ASTDLIM
<DAHDI/2-1>AGI Tx >> 200 result=1 (,)
<DAHDI/2-1>AGI Rx << GET VARIABLE ABSTIMEOUT
<DAHDI/2-1>AGI Tx >> 200 result=1 (14400)
<DAHDI/2-1>AGI Rx << EXEC Set CDR(userfield)=Analog-In
    -- AGI Script Executing Application: (Set) Options: (CDR(userfield)=Analog-In)
<DAHDI/2-1>AGI Tx >> 200 result=0
<DAHDI/2-1>AGI Rx << GET VARIABLE FAXDETECT
<DAHDI/2-1>AGI Tx >> 200 result=1 (4)
<DAHDI/2-1>AGI Rx << GET VARIABLE RINGDELAY
<DAHDI/2-1>AGI Tx >> 200 result=1 (0)
<DAHDI/2-1>AGI Rx << GET VARIABLE LTERM
<DAHDI/2-1>AGI Tx >> 200 result=1 (NO)
<DAHDI/2-1>AGI Rx << SET VARIABLE __MOH "NO"
<DAHDI/2-1>AGI Tx >> 200 result=1
<DAHDI/2-1>AGI Rx << SET CALLERID unknown
<DAHDI/2-1>AGI Tx >> 200 result=1
<DAHDI/2-1>AGI Rx << ANSWER
<DAHDI/2-1>AGI Tx >> 200 result=0
<DAHDI/2-1>AGI Rx << DATABASE GET "STAT" "OCSTAT"
<DAHDI/2-1>AGI Tx >> 200 result=0
<DAHDI/2-1>AGI Rx << SET VARIABLE REMOTENUM "Analog-In"
<DAHDI/2-1>AGI Tx >> 200 result=1
<DAHDI/2-1>AGI Rx << GET VARIABLE SYSOP
<DAHDI/2-1>AGI Tx >> 200 result=1 (500)
<DAHDI/2-1>AGI Rx << SET PRIORITY 1
<DAHDI/2-1>AGI Tx >> 200 result=0
<DAHDI/2-1>AGI Rx << SET EXTENSION 500
<DAHDI/2-1>AGI Tx >> 200 result=0
<DAHDI/2-1>AGI Rx << SET CONTEXT extensions
<DAHDI/2-1>AGI Tx >> 200 result=0
    -- <DAHDI/2-1>AGI Script sarkhpe completed, returning 0
    -- Executing [500@extensions:1] AGI("DAHDI/2-1", "sarkhpe,InCall,") in new stack
    -- Launched AGI Script /var/lib/asterisk/agi-bin/sarkhpe
<DAHDI/2-1>AGI Tx >> agi_request: sarkhpe
<DAHDI/2-1>AGI Tx >> agi_channel: DAHDI/2-1
<DAHDI/2-1>AGI Tx >> agi_language: en
<DAHDI/2-1>AGI Tx >> agi_type: DAHDI
<DAHDI/2-1>AGI Tx >> agi_uniqueid: 1307087181.7
<DAHDI/2-1>AGI Tx >> agi_version: 1.8.4
<DAHDI/2-1>AGI Tx >> agi_callerid: unknown
<DAHDI/2-1>AGI Tx >> agi_calleridname: unknown
<DAHDI/2-1>AGI Tx >> agi_callingpres: 0
<DAHDI/2-1>AGI Tx >> agi_callingani2: 0
<DAHDI/2-1>AGI Tx >> agi_callington: 0
<DAHDI/2-1>AGI Tx >> agi_callingtns: 0
<DAHDI/2-1>AGI Tx >> agi_dnid: unknown
<DAHDI/2-1>AGI Tx >> agi_rdnis: unknown
<DAHDI/2-1>AGI Tx >> agi_context: extensions
<DAHDI/2-1>AGI Tx >> agi_extension: 500
<DAHDI/2-1>AGI Tx >> agi_priority: 1
<DAHDI/2-1>AGI Tx >> agi_enhanced: 0.0
<DAHDI/2-1>AGI Tx >> agi_accountcode:
<DAHDI/2-1>AGI Tx >> agi_threadid: -1224918128
<DAHDI/2-1>AGI Tx >> agi_arg_1: InCall
<DAHDI/2-1>AGI Tx >> agi_arg_2:
<DAHDI/2-1>AGI Tx >>
<DAHDI/2-1>AGI Rx << GET VARIABLE EXTLEN
<DAHDI/2-1>AGI Tx >> 200 result=1 (3)
<DAHDI/2-1>AGI Rx << GET VARIABLE ASTDLIM
<DAHDI/2-1>AGI Tx >> 200 result=1 (,)
<DAHDI/2-1>AGI Rx << GET VARIABLE ABSTIMEOUT
<DAHDI/2-1>AGI Tx >> 200 result=1 (14400)
<DAHDI/2-1>AGI Rx << GET VARIABLE BLINDTRANSFER
<DAHDI/2-1>AGI Tx >> 200 result=0
<DAHDI/2-1>AGI Rx << GET VARIABLE VOICEINSTR
<DAHDI/2-1>AGI Tx >> 200 result=1 (YES)
<DAHDI/2-1>AGI Rx << DATABASE GET "STAT" "OCSTAT"
<DAHDI/2-1>AGI Tx >> 200 result=0
<DAHDI/2-1>AGI Rx << DATABASE GET "cfimopen" "500"
<DAHDI/2-1>AGI Tx >> 200 result=0
<DAHDI/2-1>AGI Rx << DATABASE GET "cfim" "500"
<DAHDI/2-1>AGI Tx >> 200 result=0
<DAHDI/2-1>AGI Rx << DATABASE GET "STAT" "OCSTAT"
<DAHDI/2-1>AGI Tx >> 200 result=0
<DAHDI/2-1>AGI Rx << GET VARIABLE VOICEINSTR
<DAHDI/2-1>AGI Tx >> 200 result=1 (YES)
<DAHDI/2-1>AGI Rx << DATABASE GET "cfimopen" "500"
<DAHDI/2-1>AGI Tx >> 200 result=0
<DAHDI/2-1>AGI Rx << DATABASE GET "STAT" "OCSTAT"
<DAHDI/2-1>AGI Tx >> 200 result=0
<DAHDI/2-1>AGI Rx << GET VARIABLE VOICEINSTR
<DAHDI/2-1>AGI Tx >> 200 result=1 (YES)
<DAHDI/2-1>AGI Rx << DATABASE GET "cfim" "500"
<DAHDI/2-1>AGI Tx >> 200 result=0
<DAHDI/2-1>AGI Rx << SET VARIABLE __PICKUPMARK "500"
<DAHDI/2-1>AGI Tx >> 200 result=1
<DAHDI/2-1>AGI Rx << DATABASE GET "ringdelay" "500"
<DAHDI/2-1>AGI Tx >> 200 result=0
<DAHDI/2-1>AGI Rx << GET VARIABLE INTRINGDELAY
<DAHDI/2-1>AGI Tx >> 200 result=1 (30)
<DAHDI/2-1>AGI Rx << GET VARIABLE CALLRECORD1
<DAHDI/2-1>AGI Tx >> 200 result=1 (None)
<DAHDI/2-1>AGI Rx << GET VARIABLE MOH
<DAHDI/2-1>AGI Tx >> 200 result=1 (NO)
<DAHDI/2-1>AGI Rx << EXEC Dial SIP/500,30,kt
    -- AGI Script Executing Application: (Dial) Options: (SIP/500,30,kt)
  == Using SIP RTP CoS mark 5
    -- Called 500
    -- SIP/500-00000005 is ringing
    -- SIP/500-00000005 is ringing
    -- Nobody picked up in 30000 ms
<DAHDI/2-1>AGI Tx >> 200 result=0
<DAHDI/2-1>AGI Rx << GET VARIABLE DIALSTATUS
<DAHDI/2-1>AGI Tx >> 200 result=1 (NOANSWER)
<DAHDI/2-1>AGI Rx << DATABASE GET "STAT" "OCSTAT"
<DAHDI/2-1>AGI Tx >> 200 result=0
<DAHDI/2-1>AGI Rx << GET VARIABLE VOICEINSTR
<DAHDI/2-1>AGI Tx >> 200 result=1 (YES)
<DAHDI/2-1>AGI Rx << DATABASE GET "cfbsopen" "500"
<DAHDI/2-1>AGI Tx >> 200 result=0
<DAHDI/2-1>AGI Rx << DATABASE GET "STAT" "OCSTAT"
<DAHDI/2-1>AGI Tx >> 200 result=0
<DAHDI/2-1>AGI Rx << GET VARIABLE VOICEINSTR
<DAHDI/2-1>AGI Tx >> 200 result=1 (YES)
<DAHDI/2-1>AGI Rx << DATABASE GET "cfbs" "500"
<DAHDI/2-1>AGI Tx >> 200 result=0
<DAHDI/2-1>AGI Rx << EXEC Voicemail 500,u
    -- AGI Script Executing Application: (Voicemail) Options: (500,u)
    -- <DAHDI/2-1> Playing 'vm-theperson.ulaw' (language 'en')
    -- <DAHDI/2-1> Playing 'digits/5.ulaw' (language 'en')
    -- <DAHDI/2-1> Playing 'digits/0.ulaw' (language 'en')
    -- <DAHDI/2-1> Playing 'digits/0.ulaw' (language 'en')
    -- <DAHDI/2-1> Playing 'vm-isunavail.ulaw' (language 'en')
    -- <DAHDI/2-1> Playing 'vm-intro.ulaw' (language 'en')
    -- <DAHDI/2-1> Playing 'beep.ulaw' (language 'en')
    -- Recording the message
    -- x=0, open writing:  /var/spool/asterisk/voicemail/default/500/tmp/RxLt0F format: wav49, 0x99e8020
    -- Recording automatically stopped after a silence of 6 seconds
    -- <DAHDI/2-1> Playing 'auth-thankyou.ulaw' (language 'en')
    -- Recording was 1 seconds long but needs to be at least 2 - abandoning
<DAHDI/2-1>AGI Tx >> 200 result=0
    -- <DAHDI/2-1>AGI Script sarkhpe completed, returning 0
    -- Auto fallthrough, channel 'DAHDI/2-1' status is 'NOANSWER'
    -- Executing [h@extensions:1] Hangup("DAHDI/2-1", "") in new stack
  == Spawn extension (extensions, h, 1) exited non-zero on 'DAHDI/2-1'
    -- Hanging up on 'DAHDI/2-1'
    -- Hungup 'DAHDI/2-1'

As the EXTLEN is set to 3  could the TDM settings cause an issue?

Code: [Select]

; Autogenerated by /usr/sbin/dahdi_genconf on Fri Jun  3 16:07:20 2011
; If you edit this file and execute /usr/sbin/dahdi_genconf again,
; your manual changes will be LOST.
; Dahdi Channels Configurations (chan_dahdi.conf)
;
; This is not intended to be a complete chan_dahdi.conf. Rather, it is intended
; to be #include-d by /etc/chan_dahdi.conf that will include the global settings
;

; Span 1: WCTDM/4 "Wildcard TDM400P REV I Board 5" (MASTER)
;;; line="1 WCTDM/4/0 FXSKS"
signalling=fxs_ks
callerid=asreceived
group=0
context=from-pstn
channel => 1
callerid=
group=
context=default

;;; line="2 WCTDM/4/1 FXSKS"
signalling=fxs_ks
callerid=asreceived
group=0
context=from-pstn
channel => 2
callerid=
group=
context=default

;;; line="3 WCTDM/4/2 FXOKS"
signalling=fxo_ks
callerid="Channel 3" <4003>
mailbox=4003
group=5
context=from-internal
channel => 3
callerid=
mailbox=
group=
context=default

;;; line="4 WCTDM/4/3 FXOKS"
signalling=fxo_ks
callerid="Channel 4" <4004>
mailbox=4004
group=5
context=from-internal
channel => 4
callerid=
mailbox=
group=
context=default

Thanks

[compsos]

Ok Found that switching Analog-In to the ext required worked but all pstn calls go there. No redirection according to which port it came in on.

Are these errors normal or a hint at the problem or the result of using an imported DB from 2x?

Code: [Select]

/opt/sark/scripts/update_db.sh
Applying amacs /opt/sark/amacs/r1353 to the DB
SQL error: column pkey is not unique
SQL error: column pkey is not unique
Applying amacs /opt/sark/amacs/r1397 to the DB
SQL error: duplicate column name: channel
Applying amacs /opt/sark/amacs/r1401 to the DB
SQL error: duplicate column name: ASTDLIM
SQL error: column pkey is not unique
Applying amacs /opt/sark/amacs/r1404 to the DB
SQL error: column pkey is not unique
SQL error: column pkey is not unique
Applying amacs /opt/sark/amacs/r1421 to the DB
Applying amacs /opt/sark/amacs/r1440 to the DB
SQL error: column pkey is not unique
Applying amacs /opt/sark/amacs/r1445 to the DB
Applying amacs /opt/sark/amacs/r1446 to the DB
SQL error: duplicate column name: XMPP
SQL error: duplicate column name: XMPPSERV
SQL error: column pkey is not unique
SQL error: column pkey is not unique
Applying amacs /opt/sark/amacs/r1465 to the DB
SQL error: duplicate column name: CLUSTER
SQL error: duplicate column name: dialstring
SQL error: column pkey is not unique
SQL error: column pkey is not unique
SQL error: column pkey is not unique
SQL error: column pkey is not unique
Applying amacs /opt/sark/amacs/r1482 to the DB
Applying amacs /opt/sark/amacs/r1484 to the DB
SQL error: column pkey is not unique
Applying amacs /opt/sark/amacs/r1490 to the DB
SQL error: duplicate column name: orideclosed
SQL error: duplicate column name: orideopen
SQL error: column pkey is not unique
SQL error: column pkey is not unique
Applying amacs /opt/sark/amacs/r1495 to the DB
SQL error: column pkey is not unique
Applying amacs /opt/sark/amacs/r1496 to the DB
Applying amacs /opt/sark/amacs/r1501 to the DB
Applying amacs /opt/sark/amacs/r1524 to the DB
SQL error: column pkey is not unique
SQL error: column pkey is not unique
SQL error: column pkey is not unique
SQL error: column pkey is not unique
SQL error: column pkey is not unique
Applying amacs /opt/sark/amacs/r1526 to the DB
SQL error: column pkey is not unique
SQL error: column pkey is not unique
SQL error: column pkey is not unique
SQL error: column pkey is not unique
SQL error: column pkey is not unique
Applying amacs /opt/sark/amacs/r1533 to the DB
Applying amacs /opt/sark/amacs/r1539 to the DB
SQL error: duplicate column name: trunkname
SQL error: duplicate column name: UNDOONOFF
SQL error: column pkey is not unique
SQL error: column pkey is not unique
Applying amacs /opt/sark/amacs/r1556 to the DB
SQL error: column pkey is not unique
Applying amacs /opt/sark/amacs/r1558 to the DB
SQL error: column pkey is not unique
Applying amacs /opt/sark/amacs/r1561 to the DB
SQL error: column pkey is not unique
SQL error: column pkey is not unique
SQL error: column pkey is not unique
SQL error: column pkey is not unique
SQL error: column pkey is not unique
SQL error: column pkey is not unique
SQL error: duplicate column name: openfirewall
SQL error: duplicate column name: openfirewall
SQL error: duplicate column name: subnet
SQL error: duplicate column name: subnet1
SQL error: duplicate column name: subnet2
SQL error: duplicate column name: subnetstr
SQL error: duplicate column name: subnet1str
SQL error: duplicate column name: subnet2str
SQL error: column pkey is not unique
SQL error: column pkey is not unique
SQL error: column pkey is not unique
SQL error: duplicate column name: callprogress
SQL error: column pkey is not unique
Applying amacs /opt/sark/amacs/r1577 to the DB
SQL error: duplicate column name: HAUSECLUSTER
SQL error: duplicate column name: RHINOSPF
SQL error: column pkey is not unique
SQL error: column pkey is not unique
Applying amacs /opt/sark/amacs/r1581 to the DB
Applying amacs /opt/sark/amacs/r1600 to the DB
Applying amacs /opt/sark/amacs/r1609 to the DB
SQL error: column pkey is not unique
Applying amacs /opt/sark/amacs/r1619 to the DB
Applying amacs /opt/sark/amacs/r1620 to the DB
SQL error: duplicate column name: SIPMULTICAST
SQL error: duplicate column name: ZTP
SQL error: column pkey is not unique
SQL error: column pkey is not unique
SQL error: table Device has 7 columns but 8 values were supplied
SQL error: table Device has 7 columns but 8 values were supplied
SQL error: table Device has 7 columns but 8 values were supplied
SQL error: table Device has 7 columns but 8 values were supplied


[compsos]

Hi S
The new construct in 3x of analog-in has stopped the ability to take individual PSTN lines and send to nominated extensions. Only a choice of the open or closed period settings.

How can the normal functionality/control on in coming lines be setup?

[SARK devs]

Hi Gordon,

Yes all of the analogue lines get processed the same.  Rightly or wrongly, since analogue lines don't support DiDs, segregation isn't usually required or asked for.  Most folk tend to run them as what they call either "rotaries" or "aux groups", meaning one inbound number which rings the  first (or next) free analogue line.   

I seem to think someone has segregated them out, and some others have asked for it to be segregated so I'll have  a look at it.

Kind Regards

S

[compsos]

Hi Jeff

Firstly welcome back. The forum had become very quiet. Ver 3 is looking very good, just a case of understanding new behaviours.

On ver 2 with Asterisk14 each dahdi port incoming could be pointed at an individual ext or IVR ext. So with 3 there is no way of turning off analog-in? I have changed it on the GUI from on to off but the extension.conf file and the agi ignore this and  still block switch the ports.

On another note the Sail PBX forum looks good but appears to be "being" played with by hackers. Are you planning on migrating over to this site?

[SARK devs]

Hi Gordon

Currently you can't turn off the group handler for Analog-In but I will look at segregating it in a near release.  In the interim, if you need to split then you can push the calls into an app and do it there.  The only thing that distinguishes one analogue call from another is the channel number the call came in on so I guess you would sort on that.

Re  http://sailpbx.com/forum, we put it up for EL5 and Warp users (and Ubuntu when I finally get 'round to building the deb); no plans to move away from here for SME folks.  I've removed the spam;  thanks for the heads up.

Best

Jeff   

[compsos]

Ok Next question

Under ver 2 the agi calls appear to have 4 parameters

Code: [Select]

    exten => DAHDI3-1,1,agi(selintra,Inbound,${EXTEN},DAHDI3-1)
    exten => DAHDI4-1,1,agi(selintra,Inbound,${EXTEN},DAHDI4-1)

    exten => s,1,GotoIf($["${CHANNEL}" = "DAHDI/3-1"]?DAHDI3-1,1)
    exten => s,2,GotoIf($["${CHANNEL}" = "DAHDI/4-1"]?DAHDI4-1,1)

But ver3 only 3

Code: [Select]

        exten => 6171234567,1,agi(sarkhpe,Inbound)
        exten => 6171234568,1,agi(sarkhpe,Inbound)
What will sarkhpe do in relation to a Dahdi line being passed into it? Is there any docs on the procedure?

TIA

[SARK devs]

Under ver 2 the agi calls appear to have 4 parameters...
But ver3 only 3

Yes that's true.  In V2 we explicitly sent in the extension variable ${EXTEN} which is actually superfluous because you can pick it up from the channel variables in the AGI.  When this section was rewritten in V3, we dropped the explicit variable.

You can't pass in a dahdi line unless there is a trunk entity to match it against (look at how analog-In gets processed in extensions.conf).   Essentially we need to do two things to support individual channels for you; one is to sort on channel number and the other is to create a channel entity in trunks so you can distribute the call to wherever you want it to go.

The alternative is to send analog-In calls to a custom app and do both the sort and the distribution in the app where it is entirely under your control.

Best

jeff

 

Best

jeff


   

[SARK devs]

Here is a solution from ProVu, one of our distributors....

The custom app is:

Code: [Select]

;
;       Customer Supplied Context from-my-fxo
;
[from-my-fxo]
exten => s,1,Set(CHAN=${CHANNEL:4})
exten => s,n,Set(CHAN=${CUT(CHAN,/,3)})
exten => s,n,Goto(mainmenu,fxo${CHAN},1)

Then set “context” to from-my-fxo in dahdi-channels.conf for the fxo group.

Then create DDIs in the SARK GUI such as:

fxo1 fxo2 fxo3 fxo4 etc…etc…

For however many fxo ports there are.

And point them to whatever you want. fxo1 is the first fxo port etc…


Done...

[compsos]

Hi Jeff

Thank you for the code.

Not quite working. My system passes in fxo1-1 but the DiD group will only allow setting fxo1 so as you can see below it fails to find the "extension".


Please advise if this is wrong but appears to be working OK.

Code: [Select]

;
;       Customer Supplied Context fxo-sort
;
[fxo-sort]
exten => s,1,Set(CHAN=${CHANNEL:4})
exten => s,n,Set(CHAN=${CUT(CHAN,/,2)})   <-- Split at the slash
exten => s,n,Set(CHAN=${CUT(CHAN,-,1)})   <--- Split at the dash
exten => s,n,Goto(mainmenu,fxo${CHAN},1)
Found I had to do 2 cuts to get just the correct channel number.

Code: [Select]

    -- Starting simple switch on 'DAHDI/1-1'
    -- Executing [s@fxo-sort:1] Set("DAHDI/1-1", "CHAN=I/1-1") in new stack
    -- Executing [s@fxo-sort:2] Set("DAHDI/1-1", "CHAN=1-1") in new stack
    -- Executing [s@fxo-sort:3] Set("DAHDI/1-1", "CHAN=1") in new stack
    -- Executing [s@fxo-sort:4] Goto("DAHDI/1-1", "mainmenu,fxo1,1") in new stack
    -- Goto (mainmenu,fxo1,1)
    -- Executing [fxo1@mainmenu:1] AGI("DAHDI/1-1", "sarkhpe,Inbound") in new stack
    -- Launched AGI Script /var/lib/asterisk/agi-bin/sarkhpe

This may have been just an asterisk1.8.4 issue.

A little curious about the 1st line "exten => s,1,Set(CHAN=${CHANNEL:4})" as it produces "CHAN=I/1-1". Is the "I" needed to fill the 1st element?

[SARK devs]

Sorry my mistake, I should have pointed out that the code came off of a SARK500 WARP box, which still uses 'ZAP' to address the PIKA bespoke boards.  To mod for DAHDI, you will need to increase the index accordingly (i.e. channel:6)

Best

S

[compsos]

Hi Jeff

(i.e. channel:6)

That would produce "1-1" on the first and then the separator would need to be "-" rather than "/" ?
(ie) exten => s,n,Set(CHAN=${CUT(CHAN,-,1)})

[compsos]

This code has now worked for 3 weeks. It switches incoming analogue calls to particular extensions

Code: [Select]

;
;       Customer Supplied Context fxo-sort
;
[fxo-sort]
exten => s,1,Set(CHAN=${CHANNEL:4})
exten => s,n,Set(CHAN=${CUT(CHAN,/,2)})
exten => s,n,Set(CHAN=${CUT(CHAN,-,1)})
exten => s,n,Goto(mainmenu,fxo${CHAN},1)
The incoming call will be identified as fxo1 or fxo2 .... etc
Create new trunk lines to match and set the open/closed destinations.

[SARK devs]

HI Gordon

I will look at taking this(or something very similar) into the generator in a near release.

Best

Jeff