Topic: No calls in via from-pstn blocked by incoming recording

[compsos]

Hi S
Sail 4.0.103 and 4.0.117 do the same

Any idea where the 's ' is coming from? The extensions.conf file looks correct but when we do a dialplan show from-pstn we get

Code: [Select]

[ Context 'from-pstn' created by 'pbx_config' ]
  's' =>            1. Set(chan=${CUT(CHANNEL,/,2)})              [pbx_config]
                    2. Set(chan=${CUT(chan,-,1)})                 [pbx_config]
                    3. GoTo(mainmenu,DAHDI${chan},1)              [pbx_config]
  Include =>        'mainmenu'                                    [pbx_config]

-= 1 extension (3 priorities) in 1 context. =-
The result is the same in that the call is dropped as the system does not know where to send it.

 

Code: [Select]

  -- Starting simple switch on 'DAHDI/1-1'
  == Starting DAHDI/1-1 at default,s,1 failed so falling back to exten 's'
  == Starting DAHDI/1-1 at default,s,1 still failed so falling back to context 'default'
[2014-04-11 20:54:08] WARNING[24317]: pbx.c:4971 __ast_pbx_run: Channel 'DAHDI/1-1' sent into invalid extension 's' in context 'default', but no invalid handler
    -- Hanging up on 'DAHDI/1-1'
    -- Hungup 'DAHDI/1-1'
    -- Starting simple switch on 'DAHDI/1-1'
  == Starting DAHDI/1-1 at default,s,1 failed so falling back to exten 's'
  == Starting DAHDI/1-1 at default,s,1 still failed so falling back to context 'default'
[2014-04-11 20:54:21] WARNING[24319]: pbx.c:4971 __ast_pbx_run: Channel 'DAHDI/1-1' sent into invalid extension 's' in context 'default', but no invalid handler
    -- Hanging up on 'DAHDI/1-1'
    -- Hungup 'DAHDI/1-1'

[compsos]

Is white space around '=>' important?

In the extensions.conf file the macro sections are missing it.

Code: [Select]

[macro-clear]
    exten=>s,1,System(/bin/touch /opt/sark/var/spool/asterisk/monitor/${filename})

[macro-pause]
    exten=>s,1,GoToIf($["${CHANNEL}" = "${channame}"]?:3)
        exten=>s,2,PauseMonitor
        exten=>s,3,NoOp(channel is ${CHANNEL} and channame is ${channame})

[macro-resume]
    exten=>s,1,GoToIf($["${CHANNEL}" = "${channame}"]?:3)
        exten=>s,2,UnPauseMonitor
        exten=>s,3,NoOp
I have adjusted the generator/extensions.conf to include the white space but the working file is still missing the space.

Turning off the recording monitor (inbound) cured the issue!! The system has been recording sip calls but the pstn was blocked.

Suggested corrections?

[SARK devs]

 
Whitespace/no whitespace around => - doesn't matter either way.

I think you are driving the default config from dahdi-channels (context=default).  You need to set the correct context (either mainmenu or from-pstn), both do the same thing,  SARK has no default context, it is generally regarded as a potential hack vulnerability if you have default, although most other workbenches do.

Can't comment on the recording on/off issue but might be able to if you mail me the entire extensions.conf

Best
S

[compsos]

Hi S
When we 'regenerate' the dahdi the dahdi-channels.conf file gets

Code: [Select]

; Span 1: WCTDM/4 "Wildcard TDM400P REV I Board 5" (MASTER)
;;; line="1 WCTDM/4/0 FXSKS  (EC: MG2 - INACTIVE)"
signalling=fxs_ks
callerid=asreceived
group=0
context=from-pstn
channel => 1
callerid=
group=
context=default
Note the duplicated values channel, callerid, group and context. Could this be the cause of the issue? Removing the duplicates and reactivating the inbound recording appears to work. The duplicates return on 'regenerate'. The chan_dahdi.conf is mostly commented out so would not be the source of the additional entries.
The question of the whitespace was all examples and instructions show whitespace around the '=>' and I suspected the system was not fully applying the extensions.conf file.

[SARK devs]

Hi

Yes it looks like the generator may be getting it wrong.   Unfortunately, there isn't much we can do with that because it is Digium Code; we call dahdi-genconf to do the work.    I guess you'll just have to note that it causes issues and bear it in mind for the future.   It isn't a problem on ISDN (T1/E1) channels, so it may be just with analogue.

Best

S

[compsos]

Hi S
Yes it does look that way. Just strange that it is only recently the issue started happening. All systems that I have reviewed all have the extra lines per FXO and FXS.