Outbound calls fail depending on carrier

Hello,

When I place a call to a cell phone using Verizon or AT&T the call goes through. However, when the cell phone is on T-Mobile or Google Fi (effectively T-Mobile), the call fails immediately with SIP response 486 “Busy Here.” In those cases, the target phone doesn’t ring or get a missed call notification.

I’m extremely new to Asterisk, so I’m out of ideas about how to investigate and fix this issue. Any help is appreciated :slightly_smiling_face:

Dialplan:

[outbound_twilio]
exten => _[1-9]XXXXXXXXX,1,NoOp(outbound_twilio)
  same => n,Dial(SIP/outbound_twilio/+1${EXTEN},20)

CLI call log for a failed call, T-Mobile:

== Using SIP RTP CoS mark 5
     > 0x7f1d7401e250 -- Strict RTP learning after remote address set to: 10.10.1.125:3000
  -- Executing [<phone_number>@default:1] NoOp("SIP/0101-00000014", "outbound_twilio") in new stack
  -- Executing [<phone_number>@default:2] Dial("SIP/0101-00000014", "SIP/outbound_twilio/+1<phone_number>,20") in new stack
== Using SIP RTP CoS mark 5
  -- Called SIP/outbound_twilio/+1<phone_number>
  -- Got SIP response 486 "Busy Here" back from 54.172.60.3:5060
  -- SIP/outbound_twilio-00000015 is busy
== Everyone is busy/congested at this time (1:1/0/0)
  -- Auto fallthrough, channel 'SIP/0101-00000014' status is 'BUSY'

CLI call log for a successful call, AT&T:

== Using SIP RTP CoS mark 5
     > 0x7f1d7401f760 -- Strict RTP learning after remote address set to: 10.10.1.125:3000
  -- Executing [<phone_number>@default:1] NoOp("SIP/0101-0000000a", "outbound_twilio") in new stack
  -- Executing [<phone_number>@default:2] Dial("SIP/0101-0000000a", "SIP/outbound_twilio/+1<phone_number>,20") in new stack
== Using SIP RTP CoS mark 5
  -- Called SIP/outbound_twilio/+1<phone_number>
     > 0x7f1de40074c0 -- Strict RTP learning after remote address set to: 34.203.251.243:19834
  -- SIP/outbound_twilio-0000000b is making progress passing it to SIP/0101-0000000a
  -- SIP/outbound_twilio-0000000b is ringing
WARNING[26652][C-00000006]: channel.c:4661 indicate_data_internal: Unable to handle indication 3 for 'SIP/0101-0000000a'
  -- Nobody picked up in 20000 ms
  -- Auto fallthrough, channel 'SIP/0101-0000000a' status is 'NOANSWER'
== Using SIP RTP CoS mark 5
     > 0x7f1d7401e250 -- Strict RTP learning after remote address set to: 10.10.1.125:3000
  -- Executing [<phone_number>@default:1] NoOp("SIP/0101-0000000c", "outbound_twilio") in new stack
  -- Executing [<phone_number>@default:2] Dial("SIP/0101-0000000c", "SIP/outbound_twilio/+1<phone_number>,20") in new stack
== Using SIP RTP CoS mark 5
  -- Called SIP/outbound_twilio/+1<phone_number>
     > 0x7f1dd0007fb0 -- Strict RTP learning after remote address set to: 34.203.250.227:16828
  -- SIP/outbound_twilio-0000000d is making progress passing it to SIP/0101-0000000c
  -- SIP/outbound_twilio-0000000d answered SIP/0101-0000000c
  -- Channel SIP/outbound_twilio-0000000d joined 'simple_bridge' basic-bridge <d855d624-2196-497d-8e2d-8871a96a0bfd>
  -- Channel SIP/0101-0000000c joined 'simple_bridge' basic-bridge <d855d624-2196-497d-8e2d-8871a96a0bfd>
     > Bridge d855d624-2196-497d-8e2d-8871a96a0bfd: switching from simple_bridge technology to native_rtp
     > Remotely bridged 'SIP/0101-0000000c' and 'SIP/outbound_twilio-0000000d' - media will flow directly between them
     > 0x7f1dd0007fb0 -- Strict RTP learning after remote address set to: 34.203.250.227:16828
     > 0x7f1d7401e250 -- Strict RTP learning after remote address set to: 10.10.1.125:3000
  -- Channel SIP/outbound_twilio-0000000d left 'native_rtp' basic-bridge <d855d624-2196-497d-8e2d-8871a96a0bfd>
  -- Channel SIP/0101-0000000c left 'native_rtp' basic-bridge <d855d624-2196-497d-8e2d-8871a96a0bfd>
== Spawn extension (default, <phone_number>, 2) exited non-zero on 'SIP/0101-0000000c'  

The problem seems to be being introduced by Twilio, not Asterisk.

Not sure what the issue is on the on the Twilio side (I’m new to everything there too).

I found that setting CALLERID(number) in extensions.conf or cid_number in sip.conf to one of my business’s numbers instead of leaving it as the phone’s extension seems to have fixed the issue.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.