Topic: There is a small bug in the SWOC logic for fxo (zap/dahdi) hardware

[PWDasterisk]

these are the scenarios:

A call comes in on a Zap/DAHDI FXO channel which has SWOC enabled and is set to a default open/closed destination…

>the call comes in and the CID doesn’t match any PTT_CLID trunk and the call is passed on to the default destination with the CID of the inbound call.

>the call comes in and the CID matches a PTT_CLID trunk that is set to active and the call is re-routed to the new destination with the CID of the inbound call.

>the call comes in and the CID matches a PTT_CLID trunk which exists but is NOT set to active and the call fails under the logic “Sent into invalid extension 'XXXXXXXXXX' in context 'mainmenu' on Zap/X-Y“ and the channel falls through and hangs up - however since the call was never terminated the still ringing Zap/DAHDI channel now sees this as a new call but since the CID info is only passed between the 1st and 2nd ring (in the USA) the call is now routed under the logic “callerid: unknown” so is sent to the correct destination of no matching active PTT_CLID trunk but with invalid CID info.

The only way around this is to disable the SWOC routing for the Zap trunk but then no CID routing works, or to delete the all inactive PTT_CLID trunks and then re-create them when routing is needed again - not ideal if this has to be done often. I realize that FXO hardware is not common in Europe but in the USA it is the primary interface for small business.

here is the revelant AGI debug output:

Code: [Select]

AGI Debugging Enabled
    -- SIP/BMC_SIP-089fd918 is ringing
    -- Starting simple switch on 'Zap/2-1'
    -- Executing [s@mainmenu:1] GotoIf("Zap/2-1", "0?Zap1-1|1") in new stack
    -- Executing [s@mainmenu:2] GotoIf("Zap/2-1", "1?Zap2-1|1") in new stack
    -- Goto (mainmenu,Zap2-1,1)
    -- Executing [Zap2-1@mainmenu:1] AGI("Zap/2-1", "selintra|Inbound|Zap2-1|Zap2-1") in new stack
    -- Launched AGI Script /var/lib/asterisk/agi-bin/selintra
AGI Tx >> agi_request: selintra
AGI Tx >> agi_channel: Zap/2-1
AGI Tx >> agi_language: en
AGI Tx >> agi_type: Zap
AGI Tx >> agi_uniqueid: 1274299746.93
AGI Tx >> agi_callerid: 1234567890
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: Zap2-1
AGI Tx >> agi_priority: 1
AGI Tx >> agi_enhanced: 0.0
AGI Tx >> agi_accountcode:
AGI Tx >>
AGI Rx << GET VARIABLE EXTLEN
AGI Tx >> 200 result=1 ()
AGI Rx << GET VARIABLE EXTLEN
AGI Tx >> 200 result=1 ()
AGI Rx << GET VARIABLE FAXDETECT
AGI Tx >> 200 result=1 (3)
AGI Rx << GET VARIABLE RINGDELAY
AGI Tx >> 200 result=1 (0)
AGI Rx << GET VARIABLE LTERM
AGI Tx >> 200 result=1 (NO)
AGI Rx << SET VARIABLE __MOH "NO"
AGI Tx >> 200 result=1
AGI Rx << SET CALLERID 1234567890
AGI Tx >> 200 result=1
AGI Rx << SET PRIORITY 1
AGI Tx >> 200 result=0
AGI Rx << SET EXTENSION 1234567890
AGI Tx >> 200 result=0
AGI Rx << SET CONTEXT mainmenu
AGI Tx >> 200 result=0
    -- AGI Script selintra completed, returning 0
        -- Sent into invalid extension '1234567890' in context 'mainmenu' on Zap/2-1
    -- Executing [i@mainmenu:1] PlayTones("Zap/2-1", "congestion") in new stack
  == Auto fallthrough, channel 'Zap/2-1' status is 'UNKNOWN'
    -- Executing [h@mainmenu:1] Hangup("Zap/2-1", "") in new stack
  == Spawn extension (mainmenu, h, 1) exited non-zero on 'Zap/2-1'
    -- Hungup 'Zap/2-1'
    -- Starting simple switch on 'Zap/2-1'
[May 19 16:09:15] NOTICE[1128]: chan_dahdi.c:6522 ss_thread: Got event 18 (Ring Begin)...
[May 19 16:09:18] NOTICE[1128]: chan_dahdi.c:6522 ss_thread: Got event 2 (Ring/Answered)...
    -- Executing [s@mainmenu:1] GotoIf("Zap/2-1", "0?Zap1-1|1") in new stack
    -- Executing [s@mainmenu:2] GotoIf("Zap/2-1", "1?Zap2-1|1") in new stack
    -- Goto (mainmenu,Zap2-1,1)
    -- Executing [Zap2-1@mainmenu:1] AGI("Zap/2-1", "selintra|Inbound|Zap2-1|Zap2-1") in new stack
    -- Launched AGI Script /var/lib/asterisk/agi-bin/selintra
AGI Tx >> agi_request: selintra
AGI Tx >> agi_channel: Zap/2-1
AGI Tx >> agi_language: en
AGI Tx >> agi_type: Zap
AGI Tx >> agi_uniqueid: 1274299752.94
AGI Tx >> agi_callerid: unknown
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: Zap2-1
AGI Tx >> agi_priority: 1
AGI Tx >> agi_enhanced: 0.0
AGI Tx >> agi_accountcode:
AGI Tx >>
.
.
.


[SARK devs]

Thanks PWD - excellent problem statement.

Our problem is that we can't simulate the Bell system here, BT send CLI (CLIP as they call it) using a polarity reversal before the first ring.  We'll run it on the desk using the old Mark I eyeball and see if we can't come up with a patch for you.

Kind Regards

S

   

[PWDasterisk]

forgot to mention the way I ended up working around this was to leave all PTT_CLID trunks active and just assign the open/closed destinations to match the default Zap/DAHDI open/closed destinations...

the relevance to you is that a quick fix is to disable the ACT checkbox and gray it out in the always active state and make a notation in the admin manual that the trunks have to be deleted or be manually set to the currently desired destinations.

[SARK devs]

We have set up a little sim to test this now.

We'll be back yto you once we've managed to replicate the problem.

Kind Regards

S