Outbound fails: Auto fallthrough channel status is UNKNOWN

Asterisk Asterisk Dialplan
1

Hello there,

Asterisk 22.2.0, working on a simple SLA setup. I’ve hit a wall with outbound calls. When a deskphone (in this configuration, called station4 and station5) speed dials an SLA extension (e.g. station4_line1 or station5_line1), it fails and Asterisk logs:

    -- Executing [station5_line1@sla_stations:1] SLAStation("PJSIP/station5-00000006", "station5_line1") in new stack
    -- Called disa@line1_outbound
    -- Executing [disa@line1_outbound:1] NoOp("Local/disa@line1_outbound-00000004;2", "") in new stack
    -- Executing [disa@line1_outbound:2] DISA("Local/disa@line1_outbound-00000004;2", "no-password,line1_outbound") in new stack
    -- Local/disa@line1_outbound-00000004;1 answered
    -- Auto fallthrough, channel 'PJSIP/station5-00000006' status is 'UNKNOWN'
  == Spawn extension (line1_outbound, disa, 2) exited non-zero on 'Local/disa@line1_outbound-00000004;2'

The .conf files:

; sla.conf
[general]
attemptcallerid = yes

[line1]
type = trunk
device = Local/disa@line1_outbound

[station](!)
type = station
trunk = line1

[station4](station)
device = PJSIP/station4

[station5](station)
device = PJSIP/station5

; extensions.conf
[globals]
INTERNAL_DIAL_OPT=,30

[line1]
exten => s,1,SLATrunk(line1)
exten => _X.,1,Goto(s,1)

[line1_outbound]
exten => disa,1,NoOp()
 same => n,DISA(no-password,line1_outbound)
exten => _1NXXNXXXXXX,1,Dial(PJSIP/${EXTEN}@line7777)

[sla_stations]
exten => station4,1,SLAStation(station4)
exten => station4_line1,hint,SLA:station4_line1
exten => station4_line1,1,SLAStation(station4_line1)

exten => station5,1,SLAStation(station5)
exten => station5_line1,hint,SLA:station5_line1
exten => station5_line1,1,SLAStation(station5_line1)

; pjsip.conf
[transport-udp]
type = transport
protocol = udp
bind = 0.0.0.0

[line7777]
type = endpoint
transport = transport-udp
context = line1
allow = !all,g722,ulaw
aors = line7777_aor
auth = line7777_auth
direct_media = no
dtmf_mode = auto
callerid = asreceived
trust_id_inbound = yes
send_pai = yes
send_rpid = yes
allow_subscribe = yes

[line7777_auth]
type = auth
auth_type = userpass
username = 7777
password = 7777

[line7777_aor]
type = aor
contact = sip:2.6.0.0:5062
remove_existing = yes
max_contacts = 1

[line7777_identify]
type = identify
endpoint = line7777
match = 2.6.0.0

[station](!)
type = endpoint
allow = !all,g722,ulaw
context = sla_stations
dtmf_mode = rfc4733
allow_subscribe = yes

[auth-userpass](!)
type = auth
auth_type = userpass

[aor-single-reg](!)
type = aor
max_contacts = 1

[station4](station)
auth = station4
aors = station4
callerid = "Station 4"

[station4](auth-userpass)
username = station4
password = station4

[station4](aor-single-reg)

[station5](station)
auth = station5
aors = station5
callerid = "Station 5"

[station5](auth-userpass)
username = station5
password = station5

[station5](aor-single-reg)

I’ve been whacking my head on my desk for a couple of days on this — even digging into main/pbx.c, which seems to point to DIALSTATUS isn’t available, but that’s as far as I was able to follow that lead.

Anyone have any insight?

2

I can’t help, but just be aware few people (maybe one or two) use the SLA functionality.

3

Thanks, yeah, I know it’s not a common setup.

4

Have you tryed trunk device with /n?

device = Local/disa@line1_outbound/n
5

Hi @fsilvestre,

I just tried your recommendation, but it still fails with basically the same messages:

    -- Executing [station5_line1@sla_stations:1] SLAStation("PJSIP/station5-00000008", "station5_line1") in new stack
    -- Called disa@line1_outbound/n
    -- Executing [disa@line1_outbound:1] NoOp("Local/disa@line1_outbound-00000004;2", "") in new stack
    -- Executing [disa@line1_outbound:1] DISA("Local/disa@line1_outbound-00000004;2", "no-password,line1_outbound") in new stack
    -- Local/disa@line1_outbound-00000004;1 answered
    -- Auto fallthrough, channel 'PJSIP/station5-00000008' status is 'UNKNOWN'
  == Spawn extension (line1_outbound, disa, 1) exited non-zero on 'Local/disa@line1_outbound-00000004;2'

It just appears to have /n appended to the message -- Called disa@line1_outbound/n but still fails.

6

Additional data point:

Calling in to line7777 allows me to press the line key on the deskphone assigned to the SLA and it works:

    -- Executing [7777@line1:1] Goto("PJSIP/line7777-00000022", "s,1") in new stack
    -- Goto (line1,s,1)
    -- Executing [s@line1:1] SLATrunk("PJSIP/line7777-00000022", "line1") in new stack
[May  6 13:37:12] WARNING[108684][C-0000001c]: channel.c:6351 request_channel: No channel type registered for 'DAHDI'
    -- Created MeetMe conference 1023 for conference 'SLA_line1'
[May  6 13:37:12] ERROR[108684][C-0000001c]: pbx_functions.c:700 ast_func_write: Function DENOISE not registered
    -- Called 104
    -- Called 105
    -- PJSIP/104-00000024 is ringing
    -- PJSIP/105-00000025 is ringing
       > 0x7f197007c9f0 -- Strict RTP learning after remote address set to: 2.6.0.133:16384
    -- PJSIP/105-00000025 answered
       > 0x7f19700a7d60 -- Strict RTP learning after remote address set to: 2.6.0.127:5014
[May  6 13:37:27] ERROR[108694]: pbx_functions.c:700 ast_func_write: Function DENOISE not registered
       > 0x7f197007c9f0 -- Strict RTP switching to RTP target address 2.6.0.133:16384 as source
       > 0x7f19700a7d60 -- Strict RTP switching to RTP target address 2.6.0.127:5014 as source
       > 0x7f197007c9f0 -- Strict RTP learning complete - Locking on source address 2.6.0.133:16384
       > 0x7f19700a7d60 -- Strict RTP learning complete - Locking on source address 2.6.0.127:5014
    -- Executing [101_line1@sla_stations:1] SLAStation("PJSIP/101-00000027", "101_line1") in new stack
       > 0x7f19700d29d0 -- Strict RTP learning after remote address set to: 2.6.0.129:16388
       > 0x7f19700d29d0 -- Strict RTP switching to RTP target address 2.6.0.129:16388 as source
[May  6 13:37:34] ERROR[108695][C-0000001d]: pbx_functions.c:700 ast_func_write: Function DENOISE not registered
       > 0x7f19700d29d0 -- Strict RTP learning complete - Locking on source address 2.6.0.129:16388
    -- Executing [104_line1@sla_stations:1] SLAStation("PJSIP/104-00000028", "104_line1") in new stack
       > 0x7f1970080ca0 -- Strict RTP learning after remote address set to: 2.6.0.130:16422
       > 0x7f1970080ca0 -- Strict RTP switching to RTP target address 2.6.0.130:16422 as source
[May  6 13:37:41] ERROR[108696][C-0000001e]: pbx_functions.c:700 ast_func_write: Function DENOISE not registered
[May  6 13:37:45] WARNING[108487]: res_pjsip_registrar.c:1166 find_registrar_aor: AOR '' not found for endpoint 'line7777' (2.6.0.127:5062)
       > 0x7f1970080ca0 -- Strict RTP learning complete - Locking on source address 2.6.0.130:16422
    -- Auto fallthrough, channel 'PJSIP/line7777-00000022' status is 'UNKNOWN'

(Though the final message Auto fallthrough, channel 'PJSIP/line7777-00000022' status is 'UNKNOWN' is logged, the functionality is correct for an INCOMING call).

7

Another data point:

Adding autofallthrough = no to extensions.conf under the [general] context/section results in a different kind of failure:

    -- Executing [station5_line1@sla_stations:1] SLAStation("PJSIP/station5-00000007", "station5_line1") in new stack
    -- Called disa@line1_outbound/n
    -- Executing [disa@line1_outbound:1] DISA("Local/disa@line1_outbound-00000005;2", "no-password,line1_outbound") in new stack
    -- Local/disa@line1_outbound-00000005;1 answered
  == Spawn extension (line1_outbound, disa, 1) exited non-zero on 'Local/disa@line1_outbound-00000005;2'
[May  6 14:42:33] WARNING[109420][C-0000000b]: pbx.c:4573 __ast_pbx_run: Timeout, but no rule 't' or 'e' in context 'sla_stations'

The call to DISA(no-password,line1_outbound) doesn’t seem to be working. I’ve tried testing using Playback(hello-world) but don’t hear the hello-world audio, while still seeing basically the same messages on the console.

Seems to be very close to working…

8

Auto fall through means you ran off the end of the dialplan, without hangup. If you disable it, falling off causes a go around.

9

According to the docs for SLAStation, the dialplan command only takes a single argument, being the trunk name. This is just a wild guess, but I think if you want to connect to an actual endpoint (e.g. PJSIP), you would have to specify that in a separate Dial call.

10

It looks to me as though the only documentation is probably the source code.

The applications suffer from the common problem with software documentation of failing to describe the internal states.

11

@david551 Thanks for that. I didn’t quite understand what was going on with autofallthrough=no— much appreciated.

@david551 Totally understood. More rabbit holes for me to explore…

12

@ldo Okay, so this lead me to a possibly acceptable workaround:

exten => 104,1,SLAStation(104)
exten => 104_line1,hint,SLA:104_line1
exten => 104_line1,1,SLAStation(104_line1)
 same =>           n,BridgeAdd(PJSIP/line7777)

exten => 105,1,SLAStation(105)
exten => 105_line1,hint,SLA:105_line1
exten => 105_line1,1,SLAStation(105_line1)
 same =>           n,BridgeAdd(PJSIP/line7777)

(Note I changed the extensions to be numeric — station4 is now 104, station5 is 105, etc.).

This gets me the ability to join an already established call, i.e. if 104 dials out “normally”, that is, using a line key set to extension 104, then I can use a line key on 105 set to extension 105_line1 to join the call and vice versa.

That’s a heck of a lot further than I’ve been able to get in the past few days. So thank you very much!